Madhur Amilkanthwar via llvm-dev
2020-May-30 12:52 UTC
[llvm-dev] Dynamically determine the CostPerUse value in the register allocator.
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> 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 > *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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200530/178f6314/attachment.html>
Chen, Shiva via llvm-dev
2020-Jun-02 03:11 UTC
[llvm-dev] Dynamically determine the CostPerUse value in the register allocator.
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> 於 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> 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 >> *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 >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200602/3b43c623/attachment.html>
Devadasan, Christudasan via llvm-dev
2020-Jun-02 09:11 UTC
[llvm-dev] Dynamically determine the CostPerUse value in the register allocator.
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>