[PATCH][PowerPC] Preparatory refactoring for making prologue & epilogue safe on PPC32 SVR4 ABI

Bill Schmidt wschmidt at linux.vnet.ibm.com
Fri Aug 16 10:18:09 PDT 2013


This patch LGTM (Mark ran it past me earlier).  I will regression test
it on 64-bit PPC.  Assuming that passes, I'll plan to commit on your
behalf.

Thanks,
Bill

On Fri, 2013-08-16 at 13:08 -0400, Mark Minich wrote:
>  
> 
> There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
> PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
> on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
> (and any ABI without a Red Zone), no spills may be made until after
> the stackframe is claimed, which also includes the LR spill which is
> at a positive offset. The same problem exists in emitEpilogue(),
> though there's no FIXME for it. I intend to fix this issue, making
> LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
> platforms (including in particular, OS-free embedded systems & kernel
> code, where interrupts may share the same stack as user code).
> 
>  
> 
> In preparation for making these changes, to make the diffs for the
> functional changes less cluttered, I am providing the non-functional
> refactorings in two stages:
> 
>  
> 
> Stage 1 does some minor fluffy refactorings to pull multiple method
> calls up into a single bool, creating named bools for repeated uses of
> obscure logic, moving some code up earlier because either stage 2 or
> my final version will require it earlier, and rewording/adding some
> comments. My stage 1 changes can be characterized as primarily fluffy
> cleanup, the purpose of which may be unclear until the stage 2 or
> final changes are made.
> 
>  
> 
> My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
> which is currently performed by largely duplicate code, into a single
> flow, with the differences handled by a group of constants initialized
> early in the methods.
> 
>  
> 
> This submission is for my stage 1 changes. There should be no
> functional changes whatsoever; this is a pure refactoring.
> 
>  
> 
> http://llvm-reviews.chandlerc.com/D1343
> 
>  
> 
>  
> 
>  
> 
> 





More information about the llvm-commits mailing list