While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
discovered that gcc 2.95.2 (i386) does not remove dead string
constants:
void foo (void)
{
if (0)
printk(KERN_INFO "bar");
}
Annoyingly, gcc forgets to drop the "<6>bar\0". It shows up in the
object file, needlessly clogging your cachelines.
This has ramifications for anyone thinking of converting #ifdefs to
if(){}, which is supposed to be the way of the future. In my situation
I am trying to convert '#ifdef CONFIG_MCA' to 'if (MCA_bus)' where
MCA_bus is #defined to 0 on most architectures.
'static' variables in block scope, same story.
This is mostly a heads-up to say that in this regard gcc is not ready
for prime time, so we really can't get away with using if() as an ifdef
yet, at least not without penalty.
I've just asked [email protected] about this; if I hear anything
interesting I'll report back.
Peter
On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
>
> While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> discovered that gcc 2.95.2 (i386) does not remove dead string
> constants:
>
> void foo (void)
> {
> if (0)
> printk(KERN_INFO "bar");
> }
>
> Annoyingly, gcc forgets to drop the "<6>bar\0". It shows up in the
> object file, needlessly clogging your cachelines.
gcc was never dropping such strings, I've commited a patch to fix this
a week ago into CVS.
Jakub
[Jakub Jelinek <[email protected]>]
> gcc was never dropping such strings, I've commited a patch to fix
> this a week ago into CVS.
Cool! What about block-scoped 'static' variables? Do those get
garbage-collected now as well?
Peter
On Tue, 21 Nov 2000 13:13:27 Jakub Jelinek wrote:
> On Tue, Nov 21, 2000 at 06:02:35AM -0600, Peter Samuelson wrote:
> >
> > While trying to clean up some code recently (CONFIG_MCA, hi Jeff), I
> > discovered that gcc 2.95.2 (i386) does not remove dead string
> > constants:
> >
> > void foo (void)
> > {
> > if (0)
> > printk(KERN_INFO "bar");
> > }
> >
Is it related to opt level ? -O3 does auto-inlining and -O2 does not
(discovered that here, auto inlining in kernel trashes the cache...)
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer
Linux 2.2.18-pre22-vm #7 SMP Sun Nov 19 03:29:20 CET 2000 i686 unknown
[I wrote]
> > > void foo (void)
> > > {
> > > if (0)
> > > printk(KERN_INFO "bar");
> > > }
> > >
[J . A . Magallon]
> Is it related to opt level ? -O3 does auto-inlining and -O2 does not
> (discovered that here, auto inlining in kernel trashes the cache...)
See for yourself. 'gcc -S' is most helpful. The above generates a
string constant "bar\0" for all optimization levels.
Jakub Jelinek claims to have fixed this particular bug in the last week
or so, although I have not downloaded and compiled recent CVS to verify
this. (Didn't someone at some point have a cgi frontend to
CVS-snapshot 'gcc -S'? I can't find it now.)
There is a similar case of scoped 'static' variables, like 'bar' here:
extern void baz (int *);
void foo (void)
{
if (0) {
static int bar[1024]; /* useless 4096-byte hole in bss */
baz(bar);
}
}
and according to Jeff Law, this case is *not* fixed yet.
Peter
On Tue, 21 Nov 2000, Peter Samuelson wrote:
[someone wrote, and I am keeping it :) ]
> > > > void foo (void)
> > > > {
> > > > if (0)
> > > > printk(KERN_INFO "bar");
> > > > }
> > > >
[snip]
> Jakub Jelinek claims to have fixed this particular bug in the last week
> or so, although I have not downloaded and compiled recent CVS to verify
> this. (Didn't someone at some point have a cgi frontend to
> CVS-snapshot 'gcc -S'? I can't find it now.)
It is linked from the "Reporting bugs" page on the gcc site.
http://www.codesourcery.com/gcc-compile.shtml
And as far as I can tell the assembly output of compiling "foo" does not
contain the "bar" string (without using any -O at all ...)
GCC: (GNU) 2.97 20001121 (experimental)
/Urban
> Jakub Jelinek claims to have fixed this particular bug in the last week
> or so, although I have not downloaded and compiled recent CVS to verify
> this.
I have a compiler from gcc.gnu.org's CVS tree that's only a few days old,
so I can verify Jakub's claim.
It Works For Me (tm).
There is a considerable amount of engineering and testing and releasology
and distribution between "CVS compiler" and "production compiler for
kernel builds" though.
> and according to Jeff Law, this case is *not* fixed yet.
My compiler behaves as Jeff says.
Michael Elizabeth Chastain
<mailto:[email protected]>
"love without fear"
Michael Elizabeth Chastain wrote:
> I have a compiler from gcc.gnu.org's CVS tree that's only a few days old,
> so I can verify Jakub's claim.
BTW, do you have any estimate of how much dead string space it actually
removed ? (I.e. did the .data segment size change significantly, or was
is lost in the normal inter-gcc-version noise ?)
Just curious,
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
In article <[email protected]> you wrote:
> This is mostly a heads-up to say that in this regard gcc is not ready
> for prime time, so we really can't get away with using if() as an ifdef
> yet, at least not without penalty.
Humm.. whats the Advantage of this?
Greetings
Bernd
Bernd Eckenfels wrote:
>
> In article <[email protected]> you wrote:
> > This is mostly a heads-up to say that in this regard gcc is not ready
> > for prime time, so we really can't get away with using if() as an ifdef
> > yet, at least not without penalty.
>
> Humm.. whats the Advantage of this?
Advantage of what?
If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree
with him: code looks -much- more clean without ifdefs. And the
compiler should be smart enough to completely eliminate code inside an
'if (0)' code block.
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
[Jeff Garzik]
> If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree
> with him: code looks -much- more clean without ifdefs. And the
> compiler should be smart enough to completely eliminate code inside
> an 'if (0)' code block.
Plus the advantage/disadvantage of making the compiler parse almost
everything, which should eliminate syntax errors, variable name
misspellings, etc in little-used config options. The disadvantage is
that compilation speed goes down.
Peter
On Thu, Nov 23, 2000 at 06:39:25PM -0500, Jeff Garzik wrote:
Advantage of what?
If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree
with him: code looks -much- more clean without ifdefs. And the
compiler should be smart enough to completely eliminate code inside an
'if (0)' code block.
Not only that; we should move to code where the compiler engine can
sanitize the code; the preprocessor alternative is obviously more
limited here.
The same can also be said for some of the many macro's that are
#defined; some would surely be better as inline functions is we could
ensure they would always be in-lined.
--cw
In article <[email protected]> you wrote:
> If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree
> with him: code looks -much- more clean without ifdefs. And the
> compiler should be smart enough to completely eliminate code inside an
> 'if (0)' code block.
Oh I see. Well... hmmm... I think I have no Oppionion about that :)
Greetings
Bernd