[PATCH] D17260: SystemZ scheduling implementation

[Andrew Trick via llvm-commits]

atrick added a comment.

In https://reviews.llvm.org/D17260#573123, @uweigand wrote:

> In https://reviews.llvm.org/D17260#573108, @atrick wrote:
>
> > In https://reviews.llvm.org/D17260#572785, @jonpa wrote:
> >
> > >
> >
> >
> >
> >
> > > Does anyone know how to say "Instruction B should have the same scheduling class as instruction A" ? This was the only point I could not get fixed.
> >
> > I'm not sure I understand the problem. I *think* you can mark your scheduling model "complete", then add InstAlias records in your .td file without adding new InstRW records...
>
>
> This is not about InstAlias records (which are aliases for the assembler) -- those indeed work fine.  The issue here was about aliases for the code generator.  We use those usually because some instructions need operands on the MC level that we don't want to expose on the MI level.  For example, a "return" instruction on SystemZ is actually a "br %r14", but at the MI level this doesn't have any operands, but is simply defined as an alias:
>
>   def Return : Alias<2, (outs), (ins), [(z_retflag)]>;
>
> where Alias is formally an Instruction, but doesn't have any information about mnemonic or opcodes.  Instead, when this alias is about to be emitted, we emit an actual BR instruction pattern, adding the R14 operand at this point.
>
> This means that to get a complete scheduler model, we have to duplicate the scheduling info for BR also for Return.  It would be nice if there were instead a way to say in the definition of Return to just look at BR for scheduling info.


The scheduling class is on the MCInstrDesc. AFAIK, there's no abstract way to tie your aliasing pseudo instruction's MCInstrDesc to their lowered instruction's MCInstrDesc. You can try to factor instruction records in the InstrInfo.td file itself by using a SchedRW field, but that's not the way you've structured things. I think the only reasonable thing to do here is duplicate the InstRW records. You've basically told CodeGen that these are two distinct MC instrs.


https://reviews.llvm.org/D17260