This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ARM: Invalid Stack Alignment BUG
- To: Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>
- Subject: Re: ARM: Invalid Stack Alignment BUG
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 15 Mar 2000 13:45:16 +0000
- Cc: Jeffrey A Law <law at cygnus dot com>, rth at cygnus dot com, Craig Newell <CraigN at cheque dot uq dot edu dot au>, gcc-patches at gcc dot gnu dot org, hubicka at freesoft dot cz
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
hubicka@atrey.karlin.mff.cuni.cz said:
> There is one purpose for doing the alignment to STACK_BOUNDARY in the
> backends anyway. There may be ways to use remaing few bytes as well as
> current scheme of aligning in reload is kind of wasting stack space
> (the stack boundary is repetativly aligned, not only in the last
> iteration). We was discussing this with Richard and I believe we
> concluded that proper way to handle this is to modify backends, but we
> wanted to do this later, so we did the "fix" to reload.
Just because the current implementation is not particularly efficient in
terms of stack usage doesn't mean that the rounding should be done in the
backend. Virtually every port has some definition for STACK_BOUNDARY, so
it is a gross inefficiency if every port then has to also add code to
correctly align the stack pointer. Besides which, if backends are making
adjustments to the amount of stack space pushed, how are they to know that
they haven't altered a vital offset? IMO this must be handled in a
machine independent manner, based on the information already supplied.
R.