This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC optimizes integer overflow: bug or feature?
Andrew Haley wrote:
Robert Dewar writes:
> Brooks Moses wrote:
>
> > Now, if your argument is that following the LIA-1 standard will
> > prevent optimizations that could otherwise be made if one
> > followed only the C standard, that's a reasonable argument, but
> > it should not be couched as if it implies that preventing the
> > optimizations would not be following the C standard.
>
> I continue to suspect that the gains from this optimization are minimal
> to non-existent in practice. Given the requirements in LIA-1, I would
> think that taking advantage of overflow being undefined is only
> acceptable
That's an interesting use of the passive voice. Acceptable to whom?
acceptable from a technical perspective. Damaging useability on the
basis of providing better optimization without good data showing that
the optimization is worthwhile seems unjustifiable to me. Compiler
writers overestimate the value of optimizations all the time. To me
it is essential to have data to back up arguments that optimizations
that change behavior are worth while.
For example, putting variables in registers instead of memory most
definitely changes behavior (by making uninitialized variables have
a much more deleterious effect in practice), but is easily justified
since we can easily show that many programs are really substantially
helped by this optimization.
We've already defined `-fwrapv' for people who need nonstandard
arithmetic.
Nonstandard implies that the result does not conform with the standard,
which is not correct. -fwrapv provides semantics that exactly conform
with the C standard.
But how do we know that there is any point to this option? It would
not seem hard to run a set of benchmarks. I don't have access to
helpful examples, but for what I ran, -fwrapv had no detectable
effect on performance. It sure would be nice to get at least ONE
example that is at least semi-realistic where it makes a difference.
When I worked on SPITBOL, people all the time were suggesting
optimizations in letters to the SPITBOL newsletter. I imposed
a rule saying that no one could propose an optimization unless
they could show ONE example program where the optimization could
plausibly save 5% execution time. I never got another suggestion.
I don't see that this is any different from the
interminable strict-aliasing discussion.
Yes, and sadly missing from that discussion is sufficient
concrete data, though indeed there are some examples that
we know of there, so certainly my 5% rule would apply. Even
there I would make strict-aliasing the default (I have argued
stronly for that in the GNAT context, but the back end folks
are sure (without data) that no-strict-aliasing has a
noticeable effect, so it is still the default. In practice
we advise many of our large customers to routinely use
-fno-strict-aliasing, and we have introduced a pragma to
marke individual types to suppress strict aliasing.