13 Commits

Author SHA1 Message Date
Daniil Fukalov
3031ba9545
[CodeGen] Expand power-of-2 div/rem at IR level in ExpandIRInsts. (#180654)
Previously, power-of-2 div/rem operations wider than
MaxLegalDivRemBitWidth were excluded from IR expansion and left for
backend peephole optimizations. Some backends can fail to process such
instructions in case we switch off DAGCombiner.

Now ExpandIRInsts expands them into shift/mask sequences:
- udiv X, 2^C  ->  lshr X, C
- urem X, 2^C  ->  and X, (2^C - 1)
- sdiv X, 2^C  ->  bias adjustment + ashr X, C
- srem X, 2^C  ->  X - (((X + Bias) >> C) << C)

Special cases handled:
- Division/remainder by 1 or -1 (identity, negation, or zero)
- Exact division (sdiv exact skips bias, produces ashr exact)
- Negative power-of-2 divisors (result is negated)
- INT_MIN divisor (correct via countr_zero on bit pattern)

Proofs: https://alive2.llvm.org/ce/z/Y-iWm-

Assisted-by: Cursor // Claude Opus 4.6
2026-02-25 22:54:34 +01:00
Nikita Popov
a8f211904a
[ExpandIRInsts] Support saturating fptoi (#179710)
Add support for expanding fptosi.sat and fptoui.sat via IR expansions.
Similar to fptosi/fptoui we would get legalization errors otherwise.

The previous expansion for fptosi/fptoui was already saturating -- but
those instructions do not actually require saturation, and the
implementation of the saturation was incorrect in lots of ways. What
this PR does is:

* For fptosi, remove the unnecessary saturation handling.
* For fptoui, remove the unnecessary saturation handling and sign
multiplication.
* For fptosi, use the previous saturation handling with fixes: We need
to map NaNs to 0 and the saturation condition on the exponent was
incorrect. (I'm performing the NaN check via fcmp -- there's no
requirement to do everything bitwise here.)
* For fptoui use a variation of the signed saturation handling: Negative
values need to go to zero and we saturate to unsigned max.

Proofs: https://alive2.llvm.org/ce/z/Xv9FNd
2026-02-11 14:51:30 +01:00
Nikita Popov
0287d789e0
[ExpandIRInsts] Freeze input in itofp expansion (#180157)
We are introducing branches on the value, and branch on undef/poison is
UB, so the value needs to be frozen.
2026-02-06 12:52:31 +01:00
Nikita Popov
722c2f0221
[ExpandIRInsts] Support int bw < float bw in itofp expansion (#179963)
Handle this case by extending the integer to a wider type. This can
probably be handled more optimally, but this is conservatively correct.

Proof: https://alive2.llvm.org/ce/z/0RwDO1
2026-02-05 17:26:12 +01:00
Nikita Popov
d737229efd
[ExpandIRInsts] Allow int bw == float bw in itofp (#179943)
I don't think anything here requires the integer bit width to be
strictly larger. It's fine if it's the same (in which case some zexts
just go away).

Add tests on half + i32 that can be verified by alive2. Note that half
is handled via float, so the minimum supported type is i32 rather than
i16.

Proof (uitofp): https://alive2.llvm.org/ce/z/CsMfkU
Proof (sitofp): https://alive2.llvm.org/ce/z/jzuxyt
2026-02-05 16:21:19 +01:00
Nikita Popov
516eb3820d
[ExpandIRInsts] Freeze value before fptoi expansion (#179659)
We're going to introduce new branches, and branch on undef/poison
is immediate UB.
2026-02-04 14:49:34 +01:00
Nikita Popov
3425b829f4
[ExpandIRInst] Support expanding fptoi to smaller type (#178690)
In order to support expanding fptoi where the target type is smaller,
make most of the code work on the float-as-integer type, rather than the
target type of the cast. We only need to cast the final result to the
target type, or prior to performing a left shift.

This not only allows us to handle casts to a smaller type, but also
avoids performing intermediate calculations on unnecessarily large
types.

This also matches how compiler-rt handles this:
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/fp_fixint_impl.inc

Proof: https://alive2.llvm.org/ce/z/3pJ9pE

(Note that there is a pre-existing issue that we produce the same code
for fptosi and fptoui.)
2026-01-30 09:31:05 +01:00
Nikita Popov
99e63bbbab [ExpandIRInsts] Improve variable naming
Improve naming of variables/blocks, both in the code and the
generated IR.
2026-01-29 16:45:10 +01:00
Nikita Popov
8fa48070ec [ExpandIRInsts] Simplify constant construction (NFC)
Don't go through IRBuilder for constants we can create with
APInt APIs.
2026-01-29 15:15:29 +01:00
Nikita Popov
ac039c5977 [ExpandIRInsts] Test fptoi expansion for small types
Allow testing fptoui/fptosi on half types, which are small enough
for alive2 to verify the result.

They currently pass for non-undef/poison input. (The fptoui
expansion is the same as fptosi, which is confusing, but not
incorrect, because the saturation it performs is not actually
required by fptoi.)
2026-01-29 14:59:16 +01:00
Rahul Joshi
26f962465e
[LLVM][CodeGen] Remove pass initialization calls from pass constructors (#173061)
- Remove pass initialization calls from pass constructors.
- For some passes, add the initialization to `initializeCodeGen` or
`initializeGlobalISel`.
- Remove redundant initializations from llc and X86 target for some
passes.
2026-01-21 08:44:51 -08:00
Matt Arsenault
539412914a
GlobalISel: Use LibcallLoweringInfo analysis in legalizer (#170328)
This is mostly boilerplate to move various freestanding utility
functions into LegalizerHelper. LibcallLoweringInfo is currently
optional, mostly because threading it through assorted other
uses of LegalizerHelper is more difficult.

I had a lot of trouble getting this to work in the legacy pass
manager with setRequiresCodeGenSCCOrder, and am not happy with the
result. A sub-pass manager is introduced and this is invalidated,
so we're re-computing this unnecessarily.
2026-01-16 14:42:10 +01:00
Frederik Harwath
5c05824d2b
[CodeGen] Rename expand-fp to expand-ir-insts (#172681)
The pass now contains a non-fp expansion and should
be used for any similar expansions regardless of the
types involved. Hence a generic name seems apt.

Rename the source files, pass, and adjust the pass
description. Move all tests for the expansions
that have previously been merged into the pass
to a single directory.
2025-12-18 11:15:04 +00:00