[PATCH] D17260: SystemZ scheduling implementation

[Ulrich Weigand via llvm-commits]

uweigand added a comment.

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.


https://reviews.llvm.org/D17260