This is the mail archive of the
mailing list for the GCC project.
RE: PR65416, alloca on xtensa
- From: Marc Gauthier <marc at cadence dot com>
- To: "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>, Max Filippov <jcmvbkbc at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 13 Mar 2015 10:04:54 -0700
- Subject: RE: PR65416, alloca on xtensa
- Authentication-results: sourceware.org; auth=none
- References: <CAMo8BfKLG7oVXu0SSMe9j6P5TYPYEPRJwGJ=4VbHLMR38_QS2g at mail dot gmail dot com> <CAGSvup-CbpRrdefd7RFTi-WZe-jxiqFqmi45y5OyUY2OR6PJvQ at mail dot gmail dot com>
> On Fri, Mar 13, 2015 at 7:54 AM, Max Filippov <firstname.lastname@example.org> wrote:
> > 2. alloca seems to make an additional 16-bytes padding to each stack
> > allocation: alloca(1) results in moving sp down by 32 bytes,
> > alloca(17)
> > moves it by 48 bytes, etc. This padding looks unnecessary to me:
> > either
> > this space is not used (previous register frame is not spilled), or
> > alloca
> > exception handler will take care about reloading or moving spilled
> > registers
> > to a new location. In both cases after movsp this space is just
> > wasted.
> > Do you know why this padding may be needed?
> Answering this question definitively requires some time with the ABI
> manual, which I don't have. You may be right, but I would check what
> XCC does in this case. It is far better tested.
Other than the required 16-byte stack alignment, there's nothing in
the ABI that requires these extra 16 bytes. Perhaps there was a bad
implementation of the alloca exception handler at some point a long
time ago that prompted the extra 16 bytes?
Today XCC doesn't add the extra 16 bytes. alloca(n) with n in a2
comes out as this:
0x60000490 <+12>: movi.n a8, -16
0x60000492 <+14>: addi.n a3, a2, 15
0x60000494 <+16>: and a3, a3, a8
0x60000497 <+19>: sub a3, a1, a3
0x6000049a <+22>: movsp a1, a3
which just rounds up to 16 bytes.