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

Krzysztof Parzyszek via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 17 14:09:47 PST 2015


On 11/17/2015 3:55 PM, Quentin Colombet wrote:
>
> 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?

We have custom version of assignCalleeSavedSpillSlots, where we populate 
the CSI vector with the actually saved registers, then that vector 
becomes the return value from getCalleeSavedInfo.  In a different 
function in HexagonFrameLowering (running during PEI) we go over that 
vector to generate the actual loads and stores.  We would have to do the 
assignment twice: once to fill the CSI vector, and the second time to do 
the real saving/restoring.

If only a half of a pair would need to be saved, in general we 
save/restore the whole pair.  In terms of execution time and code size 
it makes no difference.  We can lose 4 bytes on the stack, but the stack 
alignment between calls is 8 bytes anyway, so it's not a big deal.

Our customers have some code that uses fixed registers (e.g. 
-ffixed-r18), and in such cases, the assign-spill-slot function will be 
careful to avoid any references to such registers.  In these cases we 
will only store half of the pair, but we will still reserve a stack slot 
for the fixed register.  One reason for this is that an 8-byte store 
must be aligned to a 8-byte boundary: if we wanted to use that space, we 
would have to break up the remaining pairs into 4-byte stores.  We could 
coalesce the 4-byte stores at the end of the spill area to avoid this, 
but I'm not sure if we do that now.

-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