[llvm-dev] [RFC] Porting MachinePipeliner to AArch64+SVE
Florian Hahn via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 11 02:42:25 PDT 2018
On 08/06/2018 15:11, Masaki Arai via llvm-dev wrote:
> I am extending LLVM for HPC applications.
> As one of them, I am trying to make MachinePipeliner available on
> AArch64 + Scalable Vector Extension environment.
Great, thanks for looking into that.
IIUC from having a first look at your patch, there is nothing SVE
specific there so far. Although it potentially will be very useful for
SVE, it should also be beneficial for AArch64 without SVE and X86,
right? As there are no scheduling models available for SVE in LLVM yet,
I suppose it would be a good motivation if you could show some benefit
on existing AArch64 or X86 cores with your proposed modelling.
> MachinePipeliner is currently used only by Hexagon CPU.
> Since it is a very portable implementation, I think that it will
> actually work just by adding a little code for many CPUs(See Code ).
> The current MachinePipeliner is written on the premise that
> DFAPacketizer is used for resource management.
> However, I'd like to use MachinePipeliner in a way that does not use
> DFAPacketizer for the reasons described below(*).
> In MachinePipeliner implementation, only a small part is dependent on
> DFAPacketizer or Instruction itineraries.
> Therefore, I think that one of the following implementations is
> (a) creating a path in MachinePipeliner that does not use DFAPacketizer
> (b) making MachinePipeliner inheritable so that anyone can write code
> that does not use DFAPacketizer
> Since implementations using only Instruction itineraries without
> DFAPacketizer are possible, I don't think that I can use
> TargetSchedModel::hasInstrItineraries to select the execution path.
> Personally, I think that implementation of (b) is better.
IMO it makes sense to go with (b), given that the dispatch overhead
should be tiny compared to the other work that's going on and we also
added similar hooks to the generic machine scheduler recently. But it
seems like this is a smaller implementation detail and making sure we
are getting the modelling aspect right is more important.
More information about the llvm-dev