[llvm-dev] RFC: [GlobalISel] propagating int/float type information

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Mon May 4 15:19:50 PDT 2020


Hmm, I feel we would be better at fixing RBS.

I don’t think it would be necessarily expensive compile time wise to do something more sensible in RBS when running in fast:
We could defer the assignment of a register bank until we see the first real use (i.e., not a PHI or copy).

As with every heuristics, there are downsides too, but it feels to me that this is more robust than channeling metadata through a bunch of passes.

> On May 4, 2020, at 3:07 PM, Amara Emerson <aemerson at apple.com> wrote:
> 
> My thinking was no, any regbanks assigned before RBS are only hints and do not have to be preserved. But for good code it would help if the legalizer preserves them.
> 
> This issue would be there with the other approaches too. Propagating information through destructive passes like the legalizer/combined is not going to be free in any case.
> 
> Amara
> 
>> On May 4, 2020, at 2:53 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>> 
>> 
>> 
>>> On May 4, 2020, at 2:01 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>> 
>>>> On May 1, 2020, at 14:00, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote:
>>>> 
>>>> The other thing we could do is to assign speculative regbanks to vregs during translation (if the target wants to opt-in), and then RBS can finalize the regbanks, changing some if it deems it necessary/optimal.
>>> 
>>> This seems reasonable to me. It wouldn’t require any new infrastructure
>> 
>> How would that work with illegal operations?
>> 
>> Would the legalizer have to preserve them?
>> 
>> Ditto with combines.
>> 
>> What I am saying is although this does not require any new infrastructure, this is not free adopt.
>> 
>> Cheers,
>> -Quentin
>> 
>>> 
>>> -Matt
>>> _______________________________________________
>>> 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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200504/20d76b58/attachment-0001.html>


More information about the llvm-dev mailing list