mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 18:54:02 +01:00
593fc5537a
Unfortunately, it is currently impossible to use a PatFrag as part of an output
pattern (the part of the pattern that has instructions in it) in TableGen.
Looking at the current implementation, this was clearly intended to work (there
is already code in place to expand patterns in the output DAG), but is
currently broken by the baked-in type-checking assumption and the order in which
the pattern fragments are processed (output pattern fragments need to be
processed after the instruction definitions are processed).
Fixing this is fairly simple, but requires some way of differentiating output
patterns from the existing input patterns. The simplest way to handle this
seems to be to create a subclass of PatFrag, and so that's what I've done here.
As a simple example, this allows us to write:
def crnot : OutPatFrag<(ops node:$in),
(CRNOR $in, $in)>;
def : Pat<(not i1:$in),
(crnot $in)>;
which captures the core use case: handling of repeated subexpressions inside
of complicated output patterns.
This will be used by an upcoming commit to the PowerPC backend.
llvm-svn: 202450
|
||
|---|---|---|
| .. | ||
| CostTable.h | ||
| Target.td | ||
| TargetCallingConv.h | ||
| TargetCallingConv.td | ||
| TargetFrameLowering.h | ||
| TargetInstrInfo.h | ||
| TargetIntrinsicInfo.h | ||
| TargetItinerary.td | ||
| TargetJITInfo.h | ||
| TargetLibraryInfo.h | ||
| TargetLowering.h | ||
| TargetLoweringObjectFile.h | ||
| TargetMachine.h | ||
| TargetOpcodes.h | ||
| TargetOptions.h | ||
| TargetRegisterInfo.h | ||
| TargetSchedule.td | ||
| TargetSelectionDAG.td | ||
| TargetSelectionDAGInfo.h | ||
| TargetSubtargetInfo.h | ||