This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Do not consider volatile asms as optimization barriers #1
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org, Yury Gribov <y dot gribov at samsung dot com>
- Date: Mon, 03 Mar 2014 11:14:18 +0000
- Subject: Re: [RFC] Do not consider volatile asms as optimization barriers #1
- Authentication-results: sourceware.org; auth=none
- References: <2417129 dot VoWsWu5CJz at polaris> <87k3cbd83g dot fsf at talisman dot default> <CAFiYyc3PXO5g6K9gp=z+8S3hzQkVE2NP-Q-_0AZ_FXpP6YiWCQ at mail dot gmail dot com> <6212301 dot r5jUQRT7LD at polaris>
Eric Botcazou <ebotcazou@adacore.com> writes:
>> non-local labels should block most optimizations by the fact they
>> are a receiver of control flow and thus should have an abnormal
>> edge coming into them. If that's not the case (no abnormal edge)
>> then that's the bug to fix.
>
> It's (of course) more complicated, you need to look at HP's fix and testcase
> to see why we need a full optimization barrier. See also the prologue and
> epilogue of many architectures which also need a blockage when they are
> establishing or destroying the frame.
But the prologue/epilogue case often doesn't need to be a full blockage.
We could move a load-immediate instruction -- or even an accesss to known-
global memory -- before the allocation or after the deallocation. This can
actually be important on architectures that use load-multiple to restore the
return register and want the prefetcher to see the target address as early
as possible.
So I think the prologue and epilogue is one case where we really do want
to spell out what's clobbered by the allocation and deallocation.
Thanks,
Richard