[llvm-dev] Dynamically determine the CostPerUse value in the register allocator.

Tue Jun 2 02:11:59 PDT 2020

Yes, making getCostPerUse to a virtual interface will give more handle to the targets to decide how it should be done.

Regards,
Christudasan

From: Chen, Shiva <shiva.cs94g at nctu.edu.tw>
Sent: Tuesday, June 2, 2020 8:42 AM
To: Madhur Amilkanthwar <madhur13490 at gmail.com>
Cc: Devadasan, Christudasan <Christudasan.Devadasan at amd.com>; LLVM Dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Dynamically determine the CostPerUse value in the register allocator.

[CAUTION: External Email]
Hi Devadasan,

I think extending getCostPerUse as a virtual function and with MachineFunction parameter could be the first step to set up the cost. With MachineFunction, it should able to get calling convention and subtarget information.

Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> 於 2020年5月30日 週六 下午8:53寫道：
I dont know the history behind CostPerUse word so I may be missing the background associated with it. It seems that it's misnomer for what it is intended. At first sight, the word indicates that the cost is a function of uses of the register - more the uses more the cost. How do we want to define the value of CostPerUse. Should it be a function of uses? or just the target?

On Sat, May 30, 2020, 4:53 PM Devadasan, Christudasan via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

[AMD Official Use Only - Internal Distribution Only]

Please ignore the header “AMD Official Use Only”. I forgot to remove it while posting the email to llvm-dev.

Regards,
Christudasan

From: Devadasan, Christudasan
Sent: Friday, May 29, 2020 7:46 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Dynamically determine the CostPerUse value in the register allocator.

[AMD Official Use Only - Internal Distribution Only]

Hi All,

For the AMDGPU architecture, during RA, we prefer to have a cost associated with the registers (CostPerUse) based on a target entity (for instance, the Calling Convention of the current MachineFunction).
Presently CostPerUse is a one-time static value (either zero or a positive value) generated through table-gen.
The current implementation doesn’t allow us to control the reg-cost on the fly.

The AMDGPU ABI has recently been revised by introducing more caller-saved VGPRs (the exact details are explained towards the end of this e-mail), and found that having a dynamic register cost is important to achieve an optical allocation.
Precisely, it is important to limit the number of VGPRs allocated for a kernel/device-function to a smallest value since it will have a direct impact on the occupancy. The occupancy means the number of wavefronts that can be launched at runtime for a kernel program.

Some initial thoughts on how to fix it:

  1.  Have a target interface (a switch) to enable/discard the CostPerUse value.
  2.  Get the register cost in the same way we define various calling conventions (*CallingConv.td).
  3.  Compute the CostPerUse in the way the AllocationOrder for the registers is determined during RA.

The first one is the easiest method and that solves the immediate problem we currently address.
However, the other two options are better if we want to associate different reg-cost values for different calling conventions (I presume, it will arise at some point).
Other than these options, there can be a better way to fix it. Any suggestion in this regard would be helpful.

AMDGPU ABI changes and the motivation for this discussion:

Before the new ABI change:
Apart from the initial reserved 32 argument registers, all VGPRs are callee-saved registers (VGPR32 - VGPR255).
With the new ABI:
We made VGPR32 - VGPR255 into equal number of callee-saved and caller-saved registers.
For the same occupancy reason, these two sets are interleaved at a split boundary of 8.
VGPR32-VGPR39 (Caller-saved)
VGPR40-VGPR47 (Callee-saved)
VGPR48-VGPR55 (Caller-saved)
              -
              -
VGPR248-VGPR255 (Callee-saved)

With the new ABI, the allocator’s preference for callee-saved vs caller-saved depends on the input program.
RA may end up allocating more caller-saved registers than the callee-saved in certain cases. The other way of allocation is possible too (more callee-saved registers)
In either case, there will be unallocated registers left behind, bumping up the final VGPRs into a considerable number. It will have a bad impact on the occupancy.
To override the default allocation preferences of RA, we tried to set a cost for all VGPRs such that the higher indices will have higher cost.
It eliminated the problem by allocating all lower registers before picking the higher one, and with an expense of some spills in certain cases which is acceptable.

But for the kernels with no device-function calls, the register cost is unnecessary. Because there is no ABI for such kernel programs.
It caused a performance penalty for such kernels due to the register cost.
That’s the exact reason we need a method to determine dynamically either to have a reg-cost or not to have one.

Regards,
Christudasan
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7C01%7CChristudasan.Devadasan%40amd.com%7Ca60ec6007de942a309db08d806a2b8e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266643262959166&sdata=kNRaU1IZyXLSAb0luaaDT3m95QZ9sJ8hITHY0nShcdw%3D&reserved=0>
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev&data=02%7C01%7CChristudasan.Devadasan%40amd.com%7Ca60ec6007de942a309db08d806a2b8e4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266643262959166&sdata=kNRaU1IZyXLSAb0luaaDT3m95QZ9sJ8hITHY0nShcdw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200602/ade23250/attachment.html>