> If gcc caches there's no problem indeed, the problem is when it doesn't
> cache it which can happen, with volatile it will understand it must not
> make assumption for the variable to not change under it. Anyways as just
> said in another email in this thread I'm been told it wasn't just for
> 'case'. I think tomorrow Honza will comment this since he's the gcc
> developer who asked those kernel bugs to be fixed for gcc.
What I was concerned about is for example scenario:
1) cse realizes that given variable is constnat in some region of program
(by seeing an conjump).
2) it replaces occurences of other same constants in the program by that variable
(as costs says register is cheaper)
3) register allocator runs out of registers
4) reload optimizes and re-loads the variable from original place instead of
spilling it.
This way you can effectivly change one constant to another for some region
of program.
At the moment gcc rarely exploits knowledge about the variable value, but
this is going to improve, as gcc envolve and we are riscing hard to debug
problems in kernel.
I am not sure volatile is sensible solution tought.
For instance gcc 3.1 now does load store motion that makes gcc to keep
global variables in registers much longer than it did originally making
such risk greater.
Honza
>
> Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:15 EST