[PATCH] D14719: Track pristine registers in terms of register units.
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 17 13:32:20 PST 2015
> On Nov 17, 2015, at 11:29 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
>
> kparzysz added a comment.
>
> In http://reviews.llvm.org/D14719#291028, @qcolombet wrote:
>
>> [...] whether a target specific fix would be more appropriate.
>
>
> What type of approach do you have in mind for that?
Honestly, I am not sure, because I did not get what actual bug you are fixing. Of course, it is better to have a better model that does not expect consumer to do the right queries to compute the information. On the other hand, which users do you see does not make a good use of the currently produced information?
You’d mentioned the register scavenger, but AFAIR, this one does not have this problem.
> Targets that call this function themselves will sure know what to expect, my concern is about target-independent code.
I agree with your concerns, I just didn’t see them happen in practice.
> It doesn't seem like that the function getPristineRegs has a precisely defined result: it seems that the current assumption is that it will be a set of registers that is a subset of what getCalleeSavedRegs returns.
Maybe :). Where did you see this assumption at work?
> This, however, does not work for us. Should it be the all-inclusive set of registers, including all aliases that are fully covered by the pristine bits from the register file, or a minimal set of registers that cover these bits? Anything that is in between?
I think right now, this is supposed to be the minimal set of registers that cover these bits.
But I am fine with changing it. I just want to make sure we do not change it, if we decide to go in that direction, in a way that is harmful for other targets.
I think Matthias was giving it a closer look, he may have further comments.
Cheers,
-Quentin
>
>
> Repository:
> rL LLVM
>
> http://reviews.llvm.org/D14719
>
>
>
More information about the llvm-commits
mailing list