This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Add middle end hook for stack red zone size
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jiangning Liu <Jiangning dot Liu at arm dot com>, 'Joern Rennecke' <amylaar at spamcop dot net>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "vmakarov at redhat dot com" <vmakarov at redhat dot com>, "dje dot gcc at gmail dot com" <dje dot gcc at gmail dot com>, Richard Henderson <rth at redhat dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, 'Ramana Radhakrishnan' <ramana dot radhakrishnan at linaro dot org>
- Date: Mon, 01 Aug 2011 11:16:29 +0100
- Subject: Re: [RFC] Add middle end hook for stack red zone size
- References: <4e255312.0a852b0a.528d.6933SMTPIN_ADDED@mx.google.com> <CACUk7=WsaUN+TUw7rb8-o1EukoaCMrAh8bFJM6832LtRmfkofg@mail.gmail.com> <001e01cc4b33$6d3818f0$47a84ad0$@liu@arm.com> <20110725223319.petrcv01csccs44s-nzlynne@webmail.spamcop.net> <000001cc4ffd$48680ac0$d9382040$@liu@arm.com> <20110801091151.GD27949@sunsite.ms.mff.cuni.cz>
On 01/08/11 10:11, Jakub Jelinek wrote:
> On Mon, Aug 01, 2011 at 11:44:04AM +0800, Jiangning Liu wrote:
>> It's quite necessary to solve the general problem in middle-end rather than in back-end.
>
> That's what we disagree on. All back-ends but ARM are able to handle it
> right, why can't ARM too? The ABI rules for stack handling in the epilogues
> are simply too diverse and complex to be handled easily in the scheduler.
Because the vast majority of back-ends (ie those without red zones)
shouldn't have to deal with this mess. This is something the MI code
should be able to work out and deal with itself. Then the compiler will
at least generate safe code, rather than randomly moving things about
and allowing potentially unsafe writes/reads from beyond the allocated
stack region.
We should build the compiler defensively, but then allow for more
aggressive optimizations to disable the defences when the back-end wants
to take on the responsibility. Not the other way around.
R.