This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -funsafe-loop-optimizations
- From: Robert Dewar <dewar at adacore dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Richard Henderson <rth at redhat dot com>,Daniel Berlin <dberlin at dberlin dot org>,Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc at gcc dot gnu dot org
- Date: Sat, 01 Jan 2005 09:54:14 -0500
- Subject: Re: -funsafe-loop-optimizations
- References: <20041231211409.GA22814@atrey.karlin.mff.cuni.cz> <Pine.LNX.4.60.0412311649170.6844@dberlin.org> <20041231232501.GA16663@redhat.com> <200501010543.j015h3D33264@makai.watson.ibm.com>
David Edelsohn wrote:
While we discuss whether this should be the default or enabled at
any optimization level, can we agree that users should be able to assert
with a commandline option that they want less strict induction variable
semantics? I hope that we can move forward with an option to address
these performance regressions and allow users to request this optimzation
when they *do* want it, along the lines of the draft patch.
My view is that it is just fine to have command line options to modify
standard behavior. I don't even think it is terrible to have the default
be non-standard behavior if there are well defined options to get standard
behavior. I am a little uneasy about the optimization level changing the
semantics, although you can get by this by saying that something is
undefined, in which case it is fair game for optimization levels to
change the behavior.
One absolute requirement for me is that there should be a very precise
semantic definition, preferably in the framework of the semantic level
of the standard, that defines exactly what the modified semantics are
(it is fine of course for this definition to say that bla-bla-bla has
undefined semantics, but it is important that bla-bla-bla be very well
defined).
Happy New Year,
Robert
(who notes there are not too many early morning msgs on the list
this morning :-)