This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Move shift ComplexPatterns and custom isel to PatFrags with predicates
ClosedPublic

Authored by craig.topper on Nov 20 2020, 5:17 PM.

Details

Summary

ComplexPatterns are kind of weird, they don't call any of the predicates on their operands. And their "complexity" used for tablegen ordering purposes in the matcher table is hand specified.

This started as an attempt to just use sext_inreg + SLOIPat to implement SLOIW just to have one less Select function. The matching for the or+shl is the same as long as you know the immediate is less than 32 for SLOIW. But that didn't work out because using uimm5 with SLOIPat didn't do anything if it was a ComplexPattern.

I realized I could just use a PatFrag with the opcodes I wanted to match and an immediate predicate would then evaluate correctly. This also computes the complexity just like any other pattern does. Then I just needed to check the constraints on the immediates in the predicate. Conveniently the predicate is evaluated after the fragment has been matched. So the structure has already been checked, we just need to find the constants.

I'll note that this is unusual, I didn't find any other targets looking through operands in PatFrag predicate. There is a PredicateCodeUsesOperands feature that can be used to collect the operands into an array that is used by AMDGPU/VOP3Instructions.td. I believe that feature exists to handle commuted matching, but since the nodes here use constants, they aren't ever commuted.

Diff Detail

Event Timeline

craig.topper created this revision.Nov 20 2020, 5:17 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 20 2020, 5:17 PM
craig.topper requested review of this revision.Nov 20 2020, 5:17 PM
asb added a subscriber: efriedma.Dec 10 2020, 5:42 AM

Interesting. So to summarise my views on pros/cons

Pros:

  • Replacing some hand-coded pattern matching with patterns in tablegen
  • Avoid the mentioned weirdness of ComplexPattern

Cons:

  • Moves more C++ snippets into tablegen (more painful to edit and maintain proper formatting etc)
  • The fact IsRV64 is checked after PatFrag predicates is a bit surprising / easy to get wrong

Neutral:

  • Unusual approach - other targets don't seem to look through operands in PatFrag.

Overall I think being able to drop some hand-written matching means I think this makes sense. Does anyone else have views? e.g. @efriedma

Yeah so sorry I haven't provided any feedback as every time I came to it I couldn't decide where I stood. I wouldn't say I'm put off by the idea, and am probably positive about it overall, so if others are happy so am I.

Move the bodies of the PatFrags into RISCVISelDAGToDAG.cpp so we aren't putting large chunks of C++ code into tablegen.

This revision is now accepted and ready to land.Jan 5 2021, 1:51 AM