[llvm-dev] RFC: Generalizing Hexagon's VLIWMachineScheduler

[Fraser Cormack via llvm-dev]

Hi James,

I just wanted to say I think this is a good idea.

We've made use of this same Hexagon scheduler code before when starting
out with various downstream backends. Without a generic API I believe
we just ended up basically just copy/pasting the code into the
fledgling backends, which isn't ideal; I'm sorry we didn't do propose
something like what you're suggesting.

As you say, this is a useful general-purpose algorithm and so anything
that promotes code re-use is a win in my books.

Cheers,
Fraser

On Fri, 2021-10-29 at 16:58 +0000, Nagurne, James via llvm-dev wrote:
> The VLIW-aware pre-allocation scheduler used by Hexagon is a mostly-
> generic alternative to the default MachineScheduler implementation
> that attempts to order instructions in such a way as to optimize the
> number of instructions issued per cycle. It does this by tracking
> available resources (DFAPacketizer) and balancing register pressure.
> This is a departure from the default list scheduler, which has no
> resource tracking and does not attempt to model instructions
> executing in parallel, instead optimizing the straight-line path
> length of the DAG.
>  
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/Hexagon/HexagonMachineScheduler.h
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/Hexagon/HexagonMachineScheduler.cpp
>  
> I intend to generalize these data structures…
> * VLIWResourceModel
> * VLIWMachineScheduler
> * ConvergingVLIWScheduler
>  
> …by encapsulating Hexagon-specific behavior in virtual overloads of a
> generic API. There are only a couple places where target-specific
> behavior is explicit. These are identified quickly by uses of
> HexagonInstrInfo as identifier ‘QII’. The algorithm itself is likely
> tuned specifically for Hexagon, but is still generally applicable.
>  
> The port is relatively straightforward, requiring only 3 overrides.
> Testing is less defined at the moment. I’m currently running a full
> LLVM regression, but this type of change certainly prefers
> performance regressions.
>  
> Are there any opinions on lifting this pass?
>  
> Are there any publicly available Hexagon benchmarks with which I can
> verify my changes? Alternatively, are any in the Hexagon development
> team available to test such a change internally?
>  
> Regards,
> J.B. Nagurne
> Code Generation
> Texas Instruments
>  
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>