[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