| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch tracks the type of Cmm global registers. This is needed
in order to lint uses of polymorphic registers, such as SIMD vector
registers that can be used both for floating-point and integer values.
This changes allows us to refactor VanillaReg to not store VGcPtr,
as that information is instead stored in the type of the usage of the
register.
Fixes #22297
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we rework the handling of sub-word operations in the AArch64
backend, fixing a number of bugs and inconsistencies. In short,
we now impose the invariant that all subword values are represented in
registers in zero-extended form. Signed arithmetic operations are then
responsible for sign-extending as necessary.
Possible future work:
* Use `CMP`s extended register form to avoid burning an instruction
in sign-extending the second operand.
* Track sign-extension state of registers to elide redundant sign
extensions in blocks with frequent sub-word signed arithmetic.
|
| |
|
|
|
| |
This is necessary for lint-correctness since we no longer allow such
shifts in Cmm.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem
failed to narrow its arguments, meaning that a program like:
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8))
would be miscompiled. Specifically, this program should reduce as
%lobits8(0x00e1::bits16) == -31
%quot(%lobits8(0x00e1::bits16), 3::bits8) == -10
%zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) == 246
However, with this bug the `%lobits8(0x00e1::bits16)` would instead
be treated as `+31`, resulting in the incorrect result of `75`.
(cherry picked from commit 94e197e3dbb9a48991eb90a03b51ea13d39ba4cc)
|
| |
|
|
|
| |
On big-endian systems a narrow after a load cannot be replaced with
a narrow load.
|
| |
|
|
|
|
|
|
| |
Previously the `MO_S_Quot` constant folding rule would incorrectly pass
the shift amount of the same width as the shifted value. However, the
machop's type expects the shift amount to be a Word.
Fixes #20142.
|
| |
|
|
|
|
|
| |
This allows us to use the unsafe shifts in non-debug builds for performance.
For older versions of base we instead export Data.Bits
See also #19618
|
| |
|
|
|
| |
This isn't a bug yet, because we only shift native-sized types, but I
hope to change that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Optimization either returns Nothing if nothing is to be done or
`Just <cmmExpr>` otherwise. There is no point in being lazy in
`cmmExpr`. We usually inspect this element so the thunk gets forced
not long after.
We might eliminate it as dead code once in a blue moon but that's
not a case worth optimizing for.
Overall the impact of this is rather low. As Cmm.Opt doesn't allocate
much (compared to the rest of GHC) to begin with.
|
| |
|
|
|
|
|
|
|
| |
- put panic related functions into GHC.Utils.Panic
- put trace related functions using DynFlags in GHC.Driver.Ppr
One step closer making Outputable fully independent of DynFlags.
Bump haddock submodule
|
| |
|
|
|
|
|
|
|
| |
This MachOp was introduced by 2c959a1894311e59cd2fd469c1967491c1e488f3
but a wildcard match in cmmMachOpFoldM hid the fact that it wasn't
handled. Ideally we would eliminate the match but this appears to be a
larger task.
Fixes #18141.
|
| |
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
| |
|
|
|
|
|
|
| |
Metric Decrease:
ManyConstructors
T12707
T13035
T1969
|
| |
|
|
| |
submodule updates: nofib, haddock
|
| |
|
