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

Bill Schmidt wschmidt at linux.vnet.ibm.com
Fri Aug 16 13:08:31 PDT 2013


On Fri, 2013-08-16 at 12:18 -0500, Bill Schmidt wrote:
> 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.

Committed as r188573.

Bill

> 
> 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