This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: RTL alias analysis

From: Richard Henderson <rth at redhat dot com>
To: Steven Bosscher <steven at gcc dot gnu dot org>
Cc: gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Daniel Berlin <dberlin at dberlin dot org>, Jan Hubicka <jh at suse dot cz>
Date: Fri, 20 Jan 2006 13:03:19 -0800
Subject: Re: RTL alias analysis
References: <200512292242.17272.stevenb@suse.de> <43D11C2E.2020202@codesourcery.com> <200601201834.10881.steven.bosscher@gmail.com> <200601201839.21641.steven@gcc.gnu.org>

On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> FWIW, I don't believe this is a "fix", but rather a solid work-around
> for the problem.  I'm still trusting rth's superior compiler brain and
> GCC knowledge to ultimately be ingredients in a real fix ;-)

I don't think it's quite solid for a workaround.

And, unfortunately, I can't think of any "good" solution to 
the problem.  The only only way to prevent some of the 
potential problems is to prevent moving memory operations
across block boundaries, which would be a real joy for our
optimizers.

In some cases I'm sure we could see no ill effects by adding
memory barriers strategically, and in others I'm sure we'd
kill performance.

r~

Follow-Ups:
- Re: RTL alias analysis
  - From: Richard Guenther
- Re: RTL alias analysis
  - From: Mark Mitchell

References:
- Re: RTL alias analysis
  - From: Mark Mitchell
- Re: RTL alias analysis
  - From: Steven Bosscher
- Re: RTL alias analysis
  - From: Steven Bosscher

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]