<div dir="ltr"><p>Hi,</p><p>I am extending LLVM for HPC applications.<br>As one of them, I am trying to make MachinePipeliner available on<br>AArch64 + Scalable Vector Extension environment.</p><p>MachinePipeliner is currently used only by Hexagon CPU.<br>Since it is a very portable implementation, I think that it will<br>actually work just by adding a little code for many CPUs(See Code [2]).</p><p>The current MachinePipeliner is written on the premise that<br>DFAPacketizer is used for resource management.<br>However, I'd like to use MachinePipeliner in a way that does not use<br>DFAPacketizer for the reasons described below(*).<br>In MachinePipeliner implementation, only a small part is dependent on<br>DFAPacketizer or Instruction itineraries.<br>Therefore, I think that one of the following implementations is<br>possible:</p><p>(a) creating a path in MachinePipeliner that does not use DFAPacketizer<br>(b) making MachinePipeliner inheritable so that anyone can write code<br>    that does not use DFAPacketizer<br>    <br>Since implementations using only Instruction itineraries without<br>DFAPacketizer are possible, I don't think that I can use<br>TargetSchedModel::hasInstrItineraries to select the execution path.<br>Personally, I think that implementation of (b) is better.</p><p>Also, if predicated instructions like SVE are available, prologue and<br>epilogue code generation using predicated execution as shown in the<br>reference[1] may be possible.<br>In this case, if we choose the implementation of (b) and it is<br>possible to override SwingSchedulerDAG::generatePipelinedLoop, I think<br>that it can easily be extended.</p><p>Comments or suggestions are welcome.</p><p>Thank you very much.</p><p>Best regards,<br>--<br>--------------------------------------<br>Masaki Arai</p><p>========================================</p><p>(*) Currently, many CPU scheduling models are defined by the form not<br>using Instruction itineraries.<br>Therefore, they have the form 1 or 2 in the following<br>TargetSchedule.td:</p><p>// The SchedMachineModel is defined by subtargets for three categories of data:<br>// 1. Basic properties for coarse grained instruction cost model.<br>// 2. Scheduler Read/Write resources for simple per-opcode cost model.<br>// 3. Instruction itineraries for detailed reservation tables.</p><p>By making MachinePipeliner work even in a form not using Instruction<br>itineraries, we will be able to run MachinePipeliner's execution test<br>on various machines, even if we do not use it on those machines.</p><p>Instruction itineraries essentially expresses the following<br>correspondence:</p><p>  opcode ==> {FU1, FU2, ...}</p><p>and DFAPacketizer uses DFA with opcodes.<br>In order to strictly schedule predicated instructions like SVE,<br>We need to consider that following two instructions use pipeline resources<br>exclusively in the same cycle:</p><p>  MI1 if P ==> {FU1, FU2, ...}<br>  MI2 if Q ==> {FU1, FU2, ...}</p><p>where predicate P and Q hold P == not Q.<br>However, I don't think that current DFAPacketizer can represent these<br>situations.</p><p>References:</p><p>[1] Code Generation Schemas for Modulo Scheduled DO-loops and WHILE-loops<br><a href="http://www.hpl.hp.com/techreports/92/HPL-92-47.pdf?jumpid=reg_R1002_USEN">http://www.hpl.hp.com/techreports/92/HPL-92-47.pdf?jumpid=reg_R1002_USEN</a></p><p>Code:</p><p>  The sample patch for origin/release_60 [2], which doesn't use<br>  DFAPacketizer, can generate executable files from sample-code.c for<br>  both AArch64 and x86_64.</p><p>  [AArch64]% clang -O2 -mcpu=thunderx2t99 -mllvm -enable-pipeliner -mllvm -pipeliner-max=100 sample-code.c<br>  [x86_64] % clang -O2 -march=sandybridge -mllvm -enable-pipeliner -mllvm -pipeliner-max=100 sample-code.c</p><p>[2] <a href="https://reviews.llvm.org/D47943">https://reviews.llvm.org/D47943</a><br></p></div>