Re: Linux and aliasing?

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Jeffrey A Law wrote:

>   I wrote:

>   > Or those Fortran users (like me) who still do not understand how a
>   > strictly C performance enhancement can worsen the code generated for
>   > purely Fortran source, like it is the case for me (I use
>   > -fno-strict-aliasing since the end of February - and no, we Fortran
>   > users do not have a problem with aliasing; as I outlined on comp.arch,
>   > we outlawed it).

> I though this was tracked down to the inability to re-share those auto
> arrays on the stack.  I also thought we had turned off strict aliasing
> for Fortran for precisely this reason.  Did I misunderstand the end result
> of that discussion?

This was suggested, but I replied that I didn't believe that to be the
reason.  Note that Fortran basically only has one "scope" for automatic
variables (whether arrays or scalars):  The complete subprogram (i.e.
subroutine or function).

That means that in the scope Mark's alias analysis works in, automatic
arrays are created precisely once (at the beginning of that scope) and
destroyed exactly once (at the end of said scope); hence, there is no
opportunity to re-use stack slots.

Strict aliasing isn't turned off, yet (quoting f/com.c):

  /* Set default options for Fortran.  */
  flag_move_all_movables = 1;
  flag_reduce_all_givs = 1;
  flag_argument_noalias = 2;
  flag_errno_math = 0;
  flag_complex_divide_method = 1;

I also feel uneasy about just turning it off - I prefer to first *know*
why it generates worse code.

Andi Kleen wrote:

> I wrote:

>> Exactly.  Remember that a standard is a contract between producer and
>> (end-)user, in our case:  between compiler writer and C programmer.
>> 
>>       "We won't optimize your constructs away as long as you program 
>>        according to said standard"

> Erm, there seem to be some misunderstandings about the C standard in
> this discussion.

Yep, that's what you get when you want to summarize standardese in
one-liners.  Note that I later wrote about freedom for the compiler
writer vs. freedom for the programmer (I think that better catches the
spirit of the Standard).

> So it imposes no requirements on what to do when it happen. This means 
> gcc is free to do what it wants. This includes unreasonable things, or 
> reasonable things. I think turning alias analysis off in this case is 
> reasonable, and of course fully standards compliant.

Ah, yes, but the discussion is whether we should have gcc generate
"reasonable" behaviour where "reasonable" is defined by a small group of
users.  Note that all "behaviours" not explicitly required by the
Standard are prone to:

1. Erosion (within a decade, gcc maintainers forget why we did this in
   the first place: "Hey, look at this code - what hair - and it is
   undefined behaviour according to the Standard in the first place;
   rip it out")

2. Contradiction (the C0X Standard defines the previously undefined
   behaviour, but in a way incompatible with the "reasonable" behaviour
   we thought up here).

Cheers,

[In 24 hours I'm off for my first X3J3 meeting - it shows, doesn't it?]

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html