Mitchell Blank Jr wrote:
> > For uniprocessors this:
> >
> > const int cpu = smp_processor_id();
> > if (dev->xmit_lock_owner != cpu) {
> >
> > generates faster code than this:
> >
> > int cpu = smp_processor_id();
> > if (dev->xmit_lock_owner != cpu) {
>
> That's really odd, I would have assumed that gcc would have optomized
> the variable away, but your experiment indicates otherwise. Maybe we need
GCC's instruction selection method gives different results when it can
prove that a value is constant at parsing time, vs. later after CSE.
This is only true on some targets (unfortunately; it is dependent on how
the expanders (which are invoked at an early stage) and pattern matchers
(invoked later after lots of code transformation) are written in the
machine description).
So writing a constant directly can be more efficient than declareing a
variable which you never change, even a const variable. C++ has the
rule that const variables are assumed never to change, so the compiler
can treat the values as constant from the point where they're defined.
However, C does not have this rule: you can take the address of the
variable, cast to a non-const type, and change the value. For C, the
compiler must use the changed value. (At least, that was the rule at
one time; maybe it has changed now with C0X).
If the address is never taken, const or not, then the compiler knows a
variable's value is constant. However, it does not know this at the
early stage when it parses each statement and generates RTL for that
statement. As I said, some targets do limited instruction selection at
that early stage. Later, when the whole enclosing block is parsed and
you know the address was not taken, CSE can replace variable uses with
constants, constant folding is done etc. But some instruction
selections may already have been made assuming the value is not
constant.
...However, GCC treats const values differently anyway. I'm not sure
what the rules are, but const does affect the generated RTL. I do
recall that, for C, even a const variable was not as efficient as a
macro for the reason I gave earlier, for some targets (C can't assume
the value is constant). I don't know if that's still true, or if the
set of targets for which it's true has changed. E.g. the x86 backend
might be cleverer now.
enjoy,
-- 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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:11 EST