Messages in this thread | | | Date | Mon, 11 Jan 1999 08:38:05 +0000 | From | Jamie Lokier <> | Subject | Re: useful exercise |
| |
On Mon, Jan 11, 1999 at 02:12:05AM +0100, Peter T. Breuer wrote: > Do you happen to know if > > const int C_FOO = 1; > > would lead to the other branch in an if(C_FOO) being optimized away?
I'm surprised to find it depends on the version of GCC. GCC 2.7.2.3 does _not_ optimise away the branch, but EGCS 1.0.3a does. I don't know about GCC 2.8.1, as I don't have it installed.
I'm sure it once depended on C vs. C++. C would not optimise the branch, but C++ would. I recall (mistakenly?) that C++ changed the semantics of `const' to permit this sort of optimisation, while C had to allow for `*(int *)&C_FOO = 2'.
Things must have moved on, because now EGCS seems quite willing to optimise as if C_FOO is constant. This is a good thing.
> One of the things I am fairly certain of wrt gcc is that optimization is > functionwise, which means that I don't know if globals will be > considered at all when doing expression reduction.
See above. In C++ they have always been considered; it seems EGCS 1.0.3 at least considers them for C as well.
> If global constants aren't optimized as constants, then #define C_FOO > 1 is forced upon us. Pity. The int has the advantage of possibly > raising a warning in the future if used in an #ifdef (by mistake).
Well, there's not much you can do to _warn_ about #ifdef -- it is always either true or false.
However, you can have a scheme which supports `if (CONFIG_XXX)', `#if CONFIG_XXX' and `#ifdef CONFIG_XXX' all at the same time:
/* Enabled */ #define C_FOO C_FOO const int C_FOO = 1;
/* Disabled */ #undef C_BAR const int C_BAR = 0;
Do you like this? I do, if the compilers will optimise `const int'. As GCC 2.7.2.3 does _not_ optimise this, this has to be done with or after a change in the official compiler used.
In fact, I like this so much I might use it in my future programs ;-)
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |