llvm dev - Nov 2021 - RFC: Generalizing Hexagon's VLIWMachineScheduler

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211029/72c08770/attachment.html>

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
>

If you have a patch somewhere, we can give it a try.

--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at
quicinc.com>   AI tools development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagurne,
James via llvm-dev
Sent: Friday, October 29, 2021 11:59 AM
To: 'llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] RFC: Generalizing Hexagon's VLIWMachineScheduler


WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211029/f0d6f93f/attachment.html>

Thanks all for the responses.

I've uploaded a provisional diff here:

https://reviews.llvm.org/D113150

JB

From: Krzysztof Parzyszek <kparzysz at quicinc.com>
Sent: Friday, October 29, 2021 2:26 PM
To: Nagurne, James <j-nagurne at ti.com>; llvm-dev at lists.llvm.org
Subject: [EXTERNAL] RE: RFC: Generalizing Hexagon's VLIWMachineScheduler

If you have a patch somewhere, we can give it a try.

--
Krzysztof Parzyszek  kparzysz at quicinc.com<mailto:kparzysz at
quicinc.com>   AI tools development

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Nagurne, James via llvm-dev
Sent: Friday, October 29, 2021 11:59 AM
To: 'llvm-dev at lists.llvm.org' <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: [llvm-dev] RFC: Generalizing Hexagon's VLIWMachineScheduler


WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211103/8f275465/attachment-0001.html>