This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fix for execute/991221-1.c -O1 failure (fwd)
- To: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Subject: Re: fix for execute/991221-1.c -O1 failure (fwd)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 07 Mar 2000 14:42:51 -0700
- Cc: gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <200003071900.TAA26987@phal.cygnus.co.uk>you write:
> ----- Forwarded message from Joern Rennecke -----
>
> >From amylaar@cygnus.co.uk Tue Jan 4 17:07:33 2000
> >From amylaar Tue Jan 4 17:07:33 2000
> Return-Path: <amylaar@cygnus.co.uk>
> Received: (from alias@localhost)
> by cygnus.co.uk id RAA17936
> for amylaar@pasanda.cygnus.co.uk; Tue, 4 Jan 2000 17:07:32 GMT
> Received: (qmail 17926 invoked by alias); 4 Jan 2000 17:07:31 -0000
> Received: (qmail 17915 invoked from network); 4 Jan 2000 17:07:30 -0000
> Received: from phal.cygnus.co.uk (root@194.130.39.5)
> by dns.cygnus.co.uk with SMTP; 4 Jan 2000 17:07:30 -0000
> Received: (from amylaar@localhost)
> by phal.cygnus.co.uk (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA07647;
> Tue, 4 Jan 2000 17:07:22 GMT
> From: Joern Rennecke <amylaar@cygnus.co.uk>
> Message-Id: <200001041707.RAA07647@phal.cygnus.co.uk>
> Subject: Re: fix for execute/991221-1.c -O1 failure
> In-Reply-To: <17986.946974590@upchuck> from Jeffrey A Law at "Jan 4, 2000 0
> 1:29:50
> am"
> To: law@cygnus.com
> Date: Tue, 4 Jan 2000 17:07:22 +0000 (GMT)
> CC: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>,
> amylaar@cygnus.co.uk, gcc@gcc.gnu.org
> X-Mailer: ELM [version 2.4ME+ PL60 (25)]
>
> > I'd be leery of trying to do any kind of range optimizations on pointer
> > types. Especially since we have targets where we can have multiple bit
> > representations which reference the same object (function pointers for
> > PA32 runtime model for example).
>
> Well, we do now, but incorrectly. My patches aim to make the optimizations
> correct.
> I'm not sure that trying to disable the pointer optimization will be any
> simpler or safer.
But my point still stands -- I do not think it is safe to try to do range
based optimizations on pointer types. Trying to make them safe is just a
band-aid, but I don't see any way to make them work reliably on some systems.
Thus my point is we should either find a way to selectively disable them,
remove them completely, or find some subset of them we can safely perform on
all systems. I'm open to any one of those solutions, though I would tend to
be partial to removing them completely since I doubt these kinds of
optimizations are likely to apply often to pointer types (that would be an
interesting experiment -- see how often make_range actually is able to improve
some test involving pointer types).
Regardless, removing optimizations (in theory) is always the safe
thing to do -- the only way that should break things if if we do not correctly
remove the optimization, or some bug later in the compiler is exposed by
the changes.
eff