| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
