Note that 32-bit support is very limited
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86LegalizerInfo.cpp | ||
---|---|---|
208 | Just add the 32-bit handling here along with everything else? |
llvm/test/CodeGen/X86/GlobalISel/legalize-ctpop-32.mir | ||
---|---|---|
3 | Why not just add these tests to the existing legalize-ctpop.mir / legalize-leading-zeros.mir ? |
The underlying issue is that I can legalize G_CTPOP only once. There is VPOPCNTDQ and it has to be in the same builder! With the current setup, they legalize operations for different features. The famous setLegalizerInfo*functions.
If I invoke setLegalizerInfo32bit() and later setLegalizerInfoAVX512(), then G_CTPOP could be legalized twice, which is forbidden!
They rely mostly on the legacy API, where this issue does not come up. But the legacy API is less powerful. The issue is more obvious with X86, which has a wide range of features and vectors. AArch64 seems to have less issues with this constrain.
G_OR will 64bit, 128bit with SSE2, 256bit with AVX2, and 512bit with AVX512. It be a mess to create a bunch of builders for G_OR. Presumably 4 builders.
What about a class that accumulates the supported types through all the subtarget checks and then we call getActionDefinitionsBuilder once at the end with the accumulated list / settings ? I'm not sure what will happen when we start addressing custom legalization cases as well though.
@arsenm Any suggestions?
That’s what I do for some of the AMDGPU cases. Ideally the legal cases are all in the first legalization rule.
Alternatively you can always write an arbitrary legalIf predicate
It looks similarly messy. The widen rules will differ between the different vector widths.
It might be less messy with using variables instead of integer literals. maxScalarSizeand minScalarSize, something about vectors ...
I tried to unify the builders, but I failed. The root issue are std::initializerlist constructs.
rebase
Just add the 32-bit handling here along with everything else?