Re: Automaticly eliminating redundant zero initialisers

[greyham at research dot canon dot com dot au (Graham Stoney)]

[ I've dropped linux-kernel from the cc line. Once the optimisation is
[ implemented in gcc, it's trivial to enable it in the kernel build.

John Vickers writes:
> >From the last time this got batted arround on egcs/gcc:
> http://gcc.gnu.org/ml/gcc/2000-01/msg00633.html

Thanks for the pointer to the thread; I see this has indeed been discussed
before, without any real outcome. People seem to be divided into two camps:

- Those that know it will break some systems/projects, and therefore think
  it's a bad idea. Initialising a static/global variable to zero also has
  known semantics beyond merely the runtime equivalence to an uninitialised
  one, and these semantics break with this optimisation.

and

- Those that know it won't break the particular system/project they're
  interested in, and therefore would like to have the optimisation available.
  Given the runtime equivalence, they are willing to put up with the subtle
  changes in semantics to gain the space saving.

I'd like to suggest that implementing the optimisation would be valuable,
provided we can get both camps to agree under which circumstances it gets
activated/disactivated. Personally, I think it should be off by default and
get activated by -Os, but I wouldn't object to it being off all the time, and
having to use an explicit -f... option to turn it on. Make it hard to turn on
if necessary, just so long as it's possible :-).

The other question is what to call it. People have suggested:

- Hijack -fconserve-space
    Pros: The optimization does indeed conserve space.
	  The flag is already known/documented.

    Cons: It's known/documented to do something different.
	  "Conserving space" is a vague notion. -Os also conserves space.
	  There may be systems which want to "conserve space" but don't
	  initialise their .bss.

- Some inverted variant of -fno-common
    Pros: We're doing the opposite of -fno-common, so the flag should be
	  similar in name.

    Cons: The name -fno-common assumes understanding of compiler/linker
	  internals (section names) and isn't intuitive to naive users;
	  Neither would a derivative.
	  Nobody proposed/I can't think of a good name derived from it.

-fno-initialised-variables-in-bss
    Pros: Says it like it is.

    Cons: Its inverse -finitialised-variables-in-bss doesn't imply that zero
          initialisers in particular get special treatment.

- My suggestion: -fzero-bss "Assume that bss is zeroed" (off by default)
    Pros: It's telling the compiler what assumption to make, rather than
	  what action to take.
	  The complement for non-conforming systems "-fno-zero-bss" seems
	  easy to understand.
	  It could potentially be passed to the runtime build is some
	  environments in the future to control whether .bss is actually
	  zeroed.

    Cons: It's telling the compiler what assumption to make, rather than
	  what action to take.
	  .bss is zeroed in most environments, but not all may want to use to
	  flag.

- Another suggestion: -fzero-initialisers "Keep zero initalisers" (default on)
    Pros: -fno-zero-initialisers seems to make sense
	  It doesn't refer to internal section names the user might not know.

    Cons: It's unusual for "-fno-..." to enable an optimisation

If we can agree on a name, and someone submits a patch for it, would the gcc
maintainers accept it?

Regards,
Graham
-- 
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929