On 2011/3/15 02:41 PM, Ramana Radhakrishnan wrote: > On 17/02/11 10:01, Chung-Lin Tang wrote: >> Hi, >> this PR is a case where we have a leaf function with a zero-size frame, >> that calls alloca() (here through a C99 VLA). >> >> The ARM backend recognizes the leaf-and-no-frame opportunity to save an >> unneeded stack alignment. But when calling alloca(), the allocated block >> is of BIGGEST_ALIGNMENT, which is 8-bytes under current AAPCS. Thus a >> stack align may still be needed to place the alloca() returned block >> properly. >> >> This patch adjusts the early return condition with !cfun->calls_alloca. >> Tested without regressions on ARM-Linux, okay for trunk? > > OK.
Thanks. >> >> Also related, the BIGGEST_ALIGNMENT defined for ARM is currently >> ABI-based; 64-bits for AAPCS targets, and 32 for old ABI. Should this >> also consider arch-level as well? i.e. anything>= ARMv5TE (with ldrd) >> should have this set to 64. > > I don't think it's that straightforward. The ABI specifies that an 8 > byte quantity must be aligned at 64 bit boundaries and this should be > independent of architecture revisions. Think about pointers to 64 bit > quantities passed from !(TARGET_LDRD) to TARGET_LDRD code or indeed > creating structure layout issues between architecture revisions if you > change this. Oh okay, I see. I checked again, originally thought that structure layout was controlled by other alignment related macros...