This is an archive of the discontinued LLVM Phabricator instance.

[globalisel] Separate the SelectionDAG importer from the emitter. NFC
ClosedPublic

Authored by dsanders on Feb 8 2017, 3:46 AM.

Details

Summary

In the near future the rules will be sorted between these two steps to
ensure that more important rules are not prevented by less important ones.

Event Timeline

dsanders created this revision.Feb 8 2017, 3:46 AM
kristof.beyls added inline comments.Feb 8 2017, 3:53 AM
utils/TableGen/GlobalISelEmitter.cpp
562

This comment has become incorrect in the new version of the code?
Probably best to just remove?

ab added inline comments.
utils/TableGen/GlobalISelEmitter.cpp
58–59

My original thought was to replace, when we get to this point, the Optional<SkipReason> with an Expected<something>. I gave that a shot in D29743, what do you think?

dsanders added inline comments.Feb 9 2017, 2:27 AM
utils/TableGen/GlobalISelEmitter.cpp
58–59

I'm in two minds about this at the moment. I originally started this writing this patch as a transformation to Expected<RuleMatcher> but I went with the std::vector<RuleMatcher> in the end due to a need to emit multiple rules for a single pattern. I was thinking about commutativity at the time and was planning to expand, for example, (G_XOR $rs, -1) as two separate rules but I tried to implement commutativity yesterday and it's looking like it will be easier to handle that in the InstructionMatcher. However, I think the multiple-rules requirement may also arise for other cases (e.g. ComplexPattern) so I'm not entirely convinced I don't need the vector anymore.

I suppose it's best to go with Expected<RuleMatcher> until we have a pressing need to expand patterns into multiple rules at which point we can re-assess how we do this.

562

I wouldn't go as far as saying it's incorrect but I agree it's not serving any real purpose anymore. I'll remove it if we go ahead with this patch rather than D29743

ab added inline comments.Feb 9 2017, 8:17 PM
utils/TableGen/GlobalISelEmitter.cpp
58–59

IIRC things like commutativity are handled as extra PatternToMatch entries, somewhere when we do the initial CodeGenDAGPatterns parse. If that's true, it does mean we'll get mostly-identical rules. So you're right, doing something in InstructionMatcher is probably the smart move.

But either way, can't we do Expected<std::vector<RuleMatcher>> ? It's a tad more expensive, but it seems like we could still move all the RuleMatchers.

dsanders added inline comments.Feb 10 2017, 7:07 AM
utils/TableGen/GlobalISelEmitter.cpp
58–59

CodeGenDAGPatterns::AddPatternToMatch() is rejecting the commutative cases on the grounds that they can never match. This is because DAGCombiner::visitADD() canonicalizes ISD::ADD nodes such that the immediate is always on the right hand side.

dsanders updated this revision to Diff 88027.Feb 10 2017, 11:38 AM

Rebased to trunk.

ab accepted this revision.Feb 16 2017, 9:32 AM
ab added inline comments.
utils/TableGen/GlobalISelEmitter.cpp
58–59

Interesting; I suppose immediates aren't a great example, as we should also (eventually) do the canonicalization.

What about things like (mul x, (add y, z)) ? Do we need to handle commutativity for those ourselves?

This revision is now accepted and ready to land.Feb 16 2017, 9:32 AM
dsanders added inline comments.Feb 17 2017, 8:15 AM
utils/TableGen/GlobalISelEmitter.cpp
58–59

I think we do need to handle those cases. AddPatternToMatch() isn't rejecting those and both patterns show up separately in AArch64GenDAGISel.inc.

For example: AArch64 has these entries in MatcherTable:

// Src: (add:i64 (mul:i64 (sext:i64 GPR32:i32:$Rn), (imm:i64)<<P:Predicate_s64imm_32bit>>:$C), GPR64:i64:$Ra) - Complexity = 18
// Dst: (SMADDLrrr:i64 GPR32:i32:$Rn, (MOVi32imm:i32 (trunc_imm:i32 (imm:i64):$C)), GPR64:i64:$Ra)

// Src: (add:i64 GPR64:i64:$Ra, (mul:i64 (sext:i64 GPR32:i32:$Rn), (imm:i64)<<P:Predicate_s64imm_32bit>>:$C)) - Complexity = 18
// Dst: (SMADDLrrr:i64 GPR32:i32:$Rn, (MOVi32imm:i32 (trunc_imm:i32 (imm:i64):$C)), GPR64:i64:$Ra)
dsanders closed this revision.Feb 20 2017, 6:43 AM