This is an archive of the discontinued LLVM Phabricator instance.

[GlobalIsel][X86] Legalize G_CTLZ and G_CTPOP for 32-bit
ClosedPublic

Authored by tschuett on May 25 2023, 8:47 AM.

Details

Summary

Note that 32-bit support is very limited

Diff Detail

Event Timeline

tschuett created this revision.May 25 2023, 8:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 8:47 AM
tschuett requested review of this revision.May 25 2023, 8:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 8:47 AM
RKSimon added inline comments.May 25 2023, 9:55 AM
llvm/lib/Target/X86/X86LegalizerInfo.cpp
208

Just add the 32-bit handling here along with everything else?

RKSimon added inline comments.May 25 2023, 9:57 AM
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!

That sounds like a severe design flaw......

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?

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

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 ...

tschuett updated this revision to Diff 526270.EditedMay 27 2023, 8:14 AM

I tried to unify the builders, but I failed. The root issue are std::initializerlist constructs.

rebase

RKSimon accepted this revision.May 31 2023, 4:36 AM

LGTM

This revision is now accepted and ready to land.May 31 2023, 4:36 AM
This revision was landed with ongoing or failed builds.May 31 2023, 5:24 AM
This revision was automatically updated to reflect the committed changes.