Re: Wrong RTL instruction deleted

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I know this is true theoretically, but I am dubious as to whether this
    is true in practice. The only datapoint we have from a large customer
    (whose code does not work in the absence of -fno-strict-aliasing, a
    common state of affairs unfortunately), was that -O2 indeed had a very
    significant gain over -01, but the loss in using -O2 with
    -fno-strict-aliasing was negligible in comparison.

But note that this was pre-tree-ssa.  The tree optimizers make much heavier
usage of aliasing information than the RTL optimizers.  Also, we can't be
sure if the code not working with -fstrict-aliasing is due to things the code
does or a bug.  For example, running ACATS on the head showed that we don't
properly set the alias set of all subtypes of the same base array type to the
same value, as we should.

    So I am inclined to think that, at least for our commercial product,
    we would do better to set -fno-strict-aliasing by default, and then
    suggest -fstrict-aliasing as a possible path to explore for the very
    few users for whom performance at the margin is critical.

I think the jury is still very much out on this one. There are actually
*three* issues to look at:

(1) Remaining bugs in setting alias sets.
(2) Amount of optimization lost if everything is alias set 0.
(3) Detecting and warning about dubious aliasing cases.

Personally, I think (3) is key.  There simply aren't as many possible ways to
get in trouble with aliasing issues in Ada as there are in C.  We already
warn about one of them (unchecked conversions involving access types) and
there may well be more that we're missing that we could warn about (or even
handle, such as some of the unchecked conversion cases).

I think we need to take a closer look at some of those cases where strict
aliasing causes problem to see whether (1) or (3) above might apply.