[LLVMdev] x86-64 large stack offsets

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Sep 26 16:20:12 PDT 2011


On Sep 26, 2011, at 2:46 PM, David A. Greene wrote:

>> Fixing that would require the x86 backend to use the register
>> scavenger during prolog epilog insertion like the ARM backend does.
> 
> Makes sense.
> 
>> That particular code was very difficult to get right, and no one has
>> thought it was worth the trouble to get it working for x86.
> 
> I wouldn't imagine so, since these kinds of large stack objects are
> rather rare in the C world.  They are somewhat more common in the
> Fortran world.  :)
> 
>> Your life will be a whole lot easier if you just use malloc().
> 
> Perhaps.  This is customer-written code and they will (probably) not be
> willing to change it.  We could replace the allocas with malloc/free
> under the hood but we haven't needed to do that on past platforms.  It's
> certainly a mildly large change in our compiler in the sense of how
> resources get allocated.  It is certainly doable but for various reasons
> may be undesirable.
> 
> Do you have a feel for the complexity involved with the ARM code?  What
> were the troublesome parts and corner cases, etc.?

The register scavenger depends on correct kill flags after register allocation.  It will assert if it detects something hinky.

Adding scavenger support to the x86 PEI is fairly simple. Fixing the many scavenger assertions that follow is not.

The fundamental problem is that currently nothing in the x86 target depends on correct liveness after register allocation. Since many post-RA passes modify the code, there is a good chance they will update liveness incorrectly, or not at all in some cases.

Your patches to clean this up will be welcome, but please make x86's using the register scavenger enabled by a command line flag. The majority of x86 users don't want to pay the (small) compile time cost and risk of assertions.

The machine code verifier checks for the same things as the scavenger, so it should be a help to you.

/jakob




More information about the llvm-dev mailing list