[globalisel][tablegen] Import SelectionDAG's rule predicates and support the equivalent in GIRule.
ClosedPublic

Authored by dsanders on Tue, Mar 28, 3:50 AM.

Details

Summary

The SelectionDAG importer now imports rules with Predicate's attached via
Requires, PredicateControl, etc. These predicates are implemented as
bitset's to allow multiple predicates to be tested together. However,
unlike the MC layer subtarget features, each target only pays for it's own
predicates (e.g. AArch64 doesn't have 192 feature bits just because X86
needs a lot).

Both AArch64 and X86 derive at least one predicate from the MachineFunction
or Function so they must re-initialize AvailableFeatures before each
function. They also declare locals in <Target>InstructionSelector so that
computeAvailableFeatures() can use the code from SelectionDAG without
modification.

dsanders created this revision.Tue, Mar 28, 3:50 AM
ab added a comment.Mon, Apr 10, 12:56 PM

Does this really depend on D31329? Can you invert the dependency and put the tblgen emission bits in that patch?

include/llvm/CodeGen/GlobalISel/InstructionSelector.h
36–39

Can we emit this in the .inc instead?

lib/Target/AArch64/AArch64InstructionSelector.cpp
81

If we're going to access things like OptForSize directly, I'm not sure a getter for the features is valuable.

583

We already specialize the selector (and everything else) per-subtarget. Should we also treat 'optsize' and 'optnone' the same way? We wouldn't need to do anything per-function then.

That might not be a good idea, but some of our features are already not hardware-related, and seem closer to 'optsize' than to other hardware features.

584

At least for features, this should be identical across functions that we select using the same subtarget (and nothing uses the MF anyway). Should this be in the ctor? It's unfortunate they would be separate from the other predicates, but Subtarget features are the essence of the subtarget, it seems reasonable to associate them with the subtarget-specific selector.

utils/TableGen/SubtargetFeatureInfo.cpp
107–119

It would be nice to use the same ComputeAvailableFeatures. A std::bitset does let us use more than 64 features, but is any target anywhere near that?

In D31418#722861, @ab wrote:

Does this really depend on D31329? Can you invert the dependency and put the tblgen emission bits in that patch?

Yes, but only because of the test cases. I can remove the dependency fairly easily.

include/llvm/CodeGen/GlobalISel/InstructionSelector.h
36–39

I expect so. I'll look into it

lib/Target/AArch64/AArch64InstructionSelector.cpp
81

We don't normally access OptForSize directly in this implementation. It's used by ComputeAvailableFeatures() to initialize a feature bit but after that call it's unused. The only reason we store it in the class is so that the C++ code from the Predicate<> subclasses can be dropped in to ComputeAvailableFeatures() for that initialization.

583

My first attempt tried to deal with optsize/optnone inside <Target>TargetMachine::getSubtargetImpl() so that we didn't need this hook but I had problems with getting the wrong subtarget during the instruction selector. Unfortunately, I didn't manage to get to the bottom of that and I needed to move on to some dependent work so I had to fall back on this approach.

584

At least for features, this should be identical across functions that we select using the same subtarget

Agreed. There's a subtarget instance for each unique feature string.

(and nothing uses the MF anyway)

X86 needs it for NotWin64WithoutFP

Should this be in the ctor? It's unfortunate they would be separate from the other
predicates, but Subtarget features are the essence of the subtarget, it seems
reasonable to associate them with the subtarget-specific selector.

I originally wanted it in the ctor but had to move it out to support the predicates involving function attributes (e.g. optsize/optnone) and for X86's NotWin64WithoutFP.

utils/TableGen/SubtargetFeatureInfo.cpp
107–119

I agree but I think it will need to be done by moving users of the other one to this version. X86 defines 104 predicates of which 85 end up in tablegen-erated at the moment. The remainder are on rules that we don't import yet. The other implementation is limited to 64 features so we can't use that.

dsanders updated this revision to Diff 95743.Wed, Apr 19, 7:35 AM
dsanders marked 2 inline comments as done.

Tablegen-erate the PredicateBitSet definitions.

rovka accepted this revision.Thu, Apr 20, 5:10 AM

LGTM with nits.

lib/Target/AArch64/AArch64InstructionSelector.cpp
81

This getter doesn't seem to be used anymore.

utils/TableGen/SubtargetFeatureInfo.h
59

I think this function needs a more verbose comment to highlight the differences between it and emitSubtargetFeatureFlagEnumeration.

100

This has the exact same comment as emitComputeAvailableFeatures. I think you should make it more clear why we need two different functions and what each of them does.

This revision is now accepted and ready to land.Thu, Apr 20, 5:10 AM
dsanders added inline comments.Fri, Apr 21, 3:38 AM
lib/Target/AArch64/AArch64InstructionSelector.cpp
583

I believe this is the remaining thread we still need to reach a conclusion on.

Seeing as there's quite a few LGTM'd patches queued up behind this one and this is about where we handle this rather than how, I'm going to commit this patch and I'll handle whatever conclusion we reach on this post-commit. I hope that's ok with you.

dsanders edited the summary of this revision. (Show Details)Fri, Apr 21, 3:39 AM
dsanders closed this revision.Fri, Apr 21, 3:40 AM