[PATCH] D14719: Track pristine registers in terms of register units.

[Krzysztof Parzyszek via llvm-commits]

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.


-Krzysztof


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