[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