nicolas.geoffray at lip6.fr
Fri Mar 9 01:53:20 PST 2007
Chris (and everyone),
I hope I convinced you :) If it's the case, I'm checking this in.
Nicolas Geoffray wrote:
> Chris Lattner wrote:
>> Ok, so it's not related to NoFramePointerElim? If that's the case,
>> you should just have Macho and ELF return different sets of callee
>> saved regs.
> No, that's not the issue.
> Let me rephrase why I need this patch :)
> In PowerPC, whether it's on ELF ABI or MachO, R31 is a normal,
> callee-saved register. With one exception: when it is used as a frame
> pointer. When it is used as a frame pointer, both MachO and ELF remove
> R31 from the callee-saved registers set.
> There are two different ways to use R31 as a frame pointer: 1) with an
> alloca when the stack is growing in a non-compilation deterministic
> size, or 2) when NoFramePointerElim is set.
> 1) When there is an alloca that modifies the size of the stack,
> compilation goes through the LowerDYNAMIC_STACKALLOC method. In this
> method, you find the code:
> // Find out what the fix offset of the frame pointer save area.
> int FPOffset = PPCFrameInfo::getFramePointerSaveOffset(IsPPC64,
> // Allocate the frame index for frame pointer save area.
> FPSI = MF.getFrameInfo()->CreateFixedObject(IsPPC64? 8 : 4, FPOffset);
> // Save the result.
> With this code you give the info to the FrameInfo object that the frame
> pointer offset is at FPOffset. Therefore, this offset will never be used
> as an offset for another purpose. And this is _really_ important for
> ELF, because the frame pointer, R31, is saved in the callee-saved area.
> With this code, you are sure that no callee-saved register will be
> spilled to R31's offset.
> 2) When NoFramePointerElim is set, R31 is always used as a frame
> pointer. However, the stack size may be decided at a compilation time,
> therefore the compilation process never goes through the
> LowerDYNAMIC_STACKALLOC. And LowerDYNAMIC_STACKALLOC is the only method
> that saves the frame pointer offset in the frame info.
> The bug arrives here: the frame info object never had the info that R31
> is saved in the callee-saved area. Therefore, it may allocate the frame
> pointer offset for spilling an other register. This was not an issue for
> the MachO ABI because the frame pointer offset in MachO is not in the
> callee-saved area.
> With this patch I give the info to the FrameInfo object, before the
> callee-saved scan, that R31 is saved in the callee-saved area. Thus I am
> sure that no register will be spilled in R31's offset.
> I hope it's clearer now (maybe it already was, but I was getting
> confused by your replies :))
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits