[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:55:27 PST 2015


> On Nov 17, 2015, at 1:48 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
> 
> On 11/17/2015 3:32 PM, Quentin Colombet wrote:
>> 
>>> On Nov 17, 2015, at 11:29 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
>>> 
>>>  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?
> 
> In that it will always return such a subset: the set "getCalleeSavedRegs - getCalleeSavedInfo" will be a subset of getCalleeSavedRegs.
> 
> That's a weak evidence, I know.  :)
> 
> 
> To recap, the problem is that on Hexagon, the set of callee-saved registers (i.e. getCalleeSavedRegs) is expressed in terms of 32-bit registers: R16, R17, etc.  These registers can be paired into 64-bit registers, where R17:16 is called "D8", same for R19:18, etc.
> 
> When we save these registers at the beginning of the functions, we actually save the 64-bit pairs, because it's quicker to save two registers at a time.  Hence, we populate the vector getCalleSavedInfo with the 64-bit registers.
> 
> Now, when getPristineRegs calculates getCalleeSavedRegs-getCalleeSavedInfo, it takes a set with 32-bit registers and removes from it all the 64-bit registers from the second set.  Since these two sets are disjoint (even though they cover the same bits in the hardware), the set difference is the first set.  This implies that all callee-saved 32-bit registers are pristine, which is bad.

Looks like one possible target specific fix could be to return 32-bit register and pair them at the prologue/epilogue time.
Side question, what happen is you have an odd number of callee-saved registers to push?

Q.

> 
> 
> -Krzysztof
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation



More information about the llvm-commits mailing list