[llvm-dev] [RFC] Porting MachinePipeliner to AArch64+SVE

[Florian Hahn via llvm-dev]

Hi,

On 08/06/2018 15:11, Masaki Arai via llvm-dev wrote:
> Hi,
> 
> 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 [2]).
> 
> 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
> possible:
> 
> (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.

Thanks,
Florian