[llvm-dev] GlobalISel round table follow up: register bank select

[Dominik Montada via llvm-dev]

Hi all,

this is the second email for the round table follow-up, this time 
regarding the issues around the greedy RegBankSelect and alternative 
mappings.

The issue I brought up was that because RegBankSelect goes top-down, it 
never looks at all available mappings for the operands when considering 
which of the mappings to apply to the current instruction. In our 
architecture we have one register bank dedicated to pointers and another 
one for anything else. We often see code where we have a G_PTR_ADD with 
a constant. Since the constant is not a pointer, we put it on the other 
register bank. We could put it on the address regbank and do provide 
alternative mappings for that, but since the greedy algorithm doesn't 
actually check the usage of the constant, it is always put on the other 
bank.

When RegBankSelect then sees the G_PTR_ADD and sees that one of its 
inputs is on the other register bank already, it then inserts a costly 
cross-bank copy instead of checking if that operand has any alternative 
mappings which would make the overall mapping for the current 
instruction cheaper.

Matt suggested that RegBankSelect should probably go bottom-up instead 
and I agree with him. I don't think there is a particular reason why 
RegBankSelect necessarily has to go top-down.

I'm not too familiar with the implementation of RegBankSelect. Would it 
be a big effort to make it work bottom-up instead? I'm guessing one of 
the biggest areas would be the check whether a cross-bank copy is needed 
as well as calculating the overall cost for alternative mappings as now 
all usages of the current instruction would have to be checked instead 
of the much more limited operands. How big of an impact would this have?

Cheers,

Dominik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6822 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201007/02a24cbc/attachment.bin>