This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tree-ssa: a weird (mis)optimization
- From: Andrew Haley <aph at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Geert Bosch <bosch at adacore dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 1 Dec 2004 17:35:09 +0000
- Subject: Re: tree-ssa: a weird (mis)optimization
- References: <16812.39590.439732.460777@cuddles.cambridge.redhat.com><08C7A98A-42FB-11D9-91E1-000A959A128E@adacore.com><16812.47260.320238.536151@cuddles.cambridge.redhat.com><20041130224704.GA4960@redhat.com><16813.39257.780795.560709@cuddles.cambridge.redhat.com><20041201171934.GB12839@redhat.com>
Richard Henderson writes:
> On Wed, Dec 01, 2004 at 10:13:45AM +0000, Andrew Haley wrote:
> > Let me put it this way: a trapping instruction has an abnormal edge in
> > the CFG, so why would it get deleted?
>
> Well, for one, I didn't think things worked this way. It doesn't
> make a whole lot of sense to me. We work hard to *get rid* of
> instructions that trap, and to remove the associated abnormal edges.
I see.
> I still think that the Java front end should be doing something in
> order to indicate that these loads should not be removed, beyond
> just marking them as trapping -- or rather, not marking them as not
> trapping.
Well, okay. What I need is something that gets treated as
(p ? *p : throw)
... I don't want to make every load volatile, because it will cause
unnecessary loads. Once we've determined that a read from p won't
trap we don't want to read it again. So how could a front end express
such a thing?
> Otherwise -fnon-call-exceptions will suddenly generate
> *significantly* worse code for everyone else.
I guess that depends on how many unnecessary reads from memory one can
eliminate with production code. Yeah, I know...
Andrew.