Re: type based aliasing again

[craig@jcb-sc.com]

>I say we should keep user code found in real programs working, as long
>as that is easy to do.  Sometimes it is necessary or important to
>break code people use, and then it's worth doing so.  But when we have
>an easy and painless way to keep certain code working, then breaking
>it is not necessary or important, so we shouldn't.

I don't really disagree with this.  The "easy to do" part is important.

One thing I notice about, e.g., Tim Prince's occasional posts about
g77 vis-a-vis commercial compilers is that, while it sometimes suffers
in a performance comparison, it tends to more often choose code paths
(implementation alternatives might be a better terminology) consistent
with how the code actually looks.

I haven't investigated any of his examples that I can think of, so
perhaps one has to do with the other.

But if it's easy for the GCC middle/back ends to generate the "natural"
implementation, based on the input code stream (and assuming the front
end doesn't obscure that stream), in the absence of a clear preference
based on, for example, optimization, then IMO it's better for GCC
to default to that approach than otherwise.

That's because while, indeed, such a choice might (as Marc correctly
points out) generate the impression that user code works better than
it otherwise would, or will, on future architectures, better compilers,
*different* compilers, and so on, given the width and breadth of
code compiled by GCC and the programmers who write (and have written
and will write) such code, a compiler that tends to implement
code the "natural" way when there's no clear choice as to which is
best will be more apt to help the *industry* deploy more immediately
stable products overall.

I want to emphasize that "easy to do", in RMS's terms, means to me
that the compiler should *itself* never make this assessment.  It should
be made only by compiler writers, based on a cursory examination.

So I'm not suggesting anyone change GCC to implement "foo(i++,i++,i++);"
to evaluate the arguments left-to-right instead of right-to-left if *it*
can reckon there'd be no substantial performance penalty for doing so.

But I'm suggesting perhaps it *should* so implement it if there's
no *general* likelihood of a performance penalty for left-to-right
order vs. right-to-left order.  (If it's just a matter of a tm.h
macro definition or some such thing.)

It is so difficult to explain this so users don't misunderstand this
as some sort of promise for a long-term accommodation of certain sorts
of broken code, that I don't suggest we do it in anything that appears
to be user documentation.  Internal documentation, or recommendations
for how GCC (or GNU) programmers should code things?  Fine -- users
who are interested in implementation internals should read that.  Let
them therefore recognize that one of the benefits of free-software
products is that their development process is necessarily more open,
so that they aren't likely to have similar access to internal info
on proprietary software.  (If we make such statements in *user* docs,
we encourage proprietary-software makers to make similar *promises*,
which might, in the absence of internal docs, actually lead some
users to believe them.)

That being said, I've long wanted an option that I'll call, for the moment,
`-fconfound-me', that directs code generators, interpreters, and so
on to, wherever they are prepared to (and allowed by the relevant
specifications), do things in an "unexpected", rather than "natural", way,
so I could evaluate whether my code stands up to such "abuse".

That option might not reverse order of argument evaluation on an
architecture where one order will be generally more optimal than
another.

But it would cause the compiler to choose, where choices of "naturalness"
have been consciously made vis-a-vis the option, the "unnatural" path.
(In the g77 front end, this would do simple things like reverse the
order of operands in "A+B" as it presents them to the back end.  Of course,
if the back end also supports the option and reverses them.... ;-)

I'm not asking for GCC to implement this option, even as a stub for
whoever might want to start testing it within their middle/back-end
code in the future, though.

That's because, having long *wanted* such an option, I've long envisioned
what a compiler architected to support this option (and others I'd
like) would look like internally.  It's not exactly trivial, and the
complexity it would add to GCC in particular, over the long haul, could
be one of the many straws in the camel's back making it unmaintainable.

My awareness of the possible desirability of such an option might
also explain to some why I'm so hesitant about us doing anything
that might make *users* of GCC think we will always manage to
accommodate their less-than-perfect coding techniques.

In particular, once my proposed option existed and started getting
used, "clever" programmers might start to reason "well, now you can
have the compiler make better choices as to what *is* natural,
based on *dynamic* assessment of the various choices and their costs,
because that'll help support -fconfound-me too -- it can make
more-confounding choices based on recognizing their lack of substantial
performance impact on a dynamic basis".  (There are lots more
things that fall out of this, that are at least as reasonable -- I
won't go into them here, but some of them are *way* cool.)

It'd be at least as hard *then* to resist that logic as it is *now*
to resist the logic of the statement "GCC should choose the more
natural implementation unless there's a clear win for choosing some
other implementation" (which is *not* what RMS is saying, thankfully).

So I view RMS's statement about how GCC should behave, vis-a-vis
what users should expect, the way I view "the separation of church
and state" vis-a-vis the legislative/executive branches versus the
judicial branch of the US government -- the legislative/executive should
take up the standard so as to reduce the friction resulting from the
judicial stepping a tad out of line, but the latter should *never* use
that strict a standard to force the former back into line.  (NB I said
that's how *I* view that standard vis-a-vis government: I'm not
in any way asking others to view it the same way.  I might suggest
it'd lead to less friction and more freedom if the respective branches
of government viewed their responsibilities accordingly, based on
a more engineering-like view of "tolerance".  But I haven't read
the legislative and judicial history of the standard itself, so
my analysis is not a "legal" one.)

I.e. we should decide for *ourselves* as GCC developers (and of course
users can send in patches if they like) to what degree we can and
should support "naturalness".  As long as we make a good-faith
attempt to do so, reasonable, even *slightly* extreme, users will
ultimately appreciate our efforts.

But when *users* claim GCC didn't choose a "natural" implementation
for some construct and thus broke (or, more precisely, exposed breakage
in) their code, we should, as developers, make it clear *to users*
(even if we might go the extra mile ourselves to help) that it is
up to *them* to show that the choice GCC made couldn't have benefited
performance in any general circumstance *and* is easy for GCC to
choose differently.  The default response should be "GCC is generating
code in line with the pertinent standards and specifications, which
is all you should expect", so that any extra help we give is clearly
seen to proceed from that basis.

In the end, the caveat "easy to do" carries with it so much more
than mere ease of coding, or even ease of decision-making, when
*implementing* the compiler.  If we in any way make this promise
to *users* of GCC, we invite negative feedback in so many potential
cases, that the end result could be that *very* little "naturalness"
ends up as "easy to do" -- thanks to all the hassles of getting
into discussions like this over every little implementation detail.

So, if the GCC Steering Committee decided to drop RMS's advice for now,
on the basis that GCC wasn't yet close to meeting the *basic* promises
of standards conformance and adequate specification of extensions,
so all effort needed to be concentrated there and not at low-level
implementation details (and discussions arising therefrom), I wouldn't
disagree with that either.  (Though I think g77 is meeting FORTRAN 77
standards conformance well enough already, and probably the same is
true for the C compiler as well...but g++, I don't know.  And we're
mostly in the same boat here: if the g++ people are still working
hard just to conform to a moving-target standard *and* their work
requires getting basic conformance in the middle/back end *and* that
affects gcc/g77, then it might indeed be wise to not attempt to meet
RMS's standard vis-a-vis even gcc and g77 until things "settle down"
in the middle/back end.)

        tq vm, (burley)