This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Porting libsanitizer to aarch64
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Christophe Lyon <christophe dot lyon at linaro dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 23 May 2013 18:36:13 +0200
- Subject: Re: Porting libsanitizer to aarch64
- References: <CAKdteOa-UDeo5zDwCeYSydu0K-WqmTjPgj3sYUpKrc0YPoncCg at mail dot gmail dot com> <20130521154426 dot GA1377 at tucnak dot redhat dot com> <CAGQ9bdyXCWDt0FF4+F5_4LbW7XcZACczKfHhr28nnwk96rf5Mw at mail dot gmail dot com> <20130522074341 dot GC1377 at tucnak dot redhat dot com> <519D2839 dot 5070602 at redhat dot com> <519E43AD dot 60002 at arm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 23, 2013 at 05:28:29PM +0100, Richard Earnshaw wrote:
> >FWIW, I would actually recommend against conditionalizing FRAME_GROWS_DOWNWARD
> >for a new port. Just make it _always_ grow down and save yourself the
> >additional code bloat in the backend.
>
> Doing that would add significantly to the cost of setting up the frame.
Why?
> FRAME_GROWS_DOWNWARD
> Define this macro to nonzero value if the addresses of local
> variable slots are at negative offsets from the frame pointer.
Yes, but this usually talks about the eliminable soft frame pointer,
something that can be eliminated later on to hard frame pointer or stack
pointer. So, if right now say you are eliminating soft frame pointer
to hard frame pointer with offset zero, you could eliminate it to
hard frame pointer minus frame size instead or vice versa (haven't looked
what aarch64 does now).
Jakub