Messages in this thread | | | Date | Mon, 19 Jul 1999 18:17:58 +0200 | From | Artur Skawina <> | Subject | Re: what libc+compiler is in use for development? |
| |
Horst von Brand wrote: > > > > unfortunately), not a gcc bug; BTW this inhibits useful optimizations).
> > comment here's an asm diff (34k) between a kernel compiled (1) with that > > option, and (2) w/o -fno-strict-aliasing. judge for yourself... > > > > http://www.geocities.com/SiliconValley/Heights/6494/sw/difffnsa.txt.gz > > > > [kernel 2.3.5+lots of patches, gcc2.95-19990716, CFLAGS as in 2.3.11, > > configured for 686, +/- std config (ide+scsi+most of networking)] > > > > (it doesn't show anything wrt correctness; just what gcc2.95's > > "strict aliasing" means for code generation) > > The "correctness" bothers me a bit: A kernel without -fno-strict-aliasing > doesn't boot here. Might be a blessing ;-)
yep. fwiw my kernels no longer work when compiled with egcs1.x; i know what triggers the problem, but haven't enabled the workaround - i'd rather not take the chance something similar could be happening somewhere else, only silently. (as gcc2.95 produces working kernels again, i haven't investigated the failure properly)
> Could you give a summary of your findings?
given the amount of dicussion about this issue, i got the impression the strict aliasing stuff was actually a worthwhile optimization. However after seeing what it does for the kernel case, i don't think it's worth the effort it would take to audit/fix the code. (this even assuming there will be a __norestrict/attribute((mayalias)) qualifier in a future gcc) Even if all current "illegal" references are fixed/marked as such, new code (drivers/subsystems) is likely to reintroduce some problems, which would then silently bite you.
Bottom line: -fno-strict-aliasing isn't very expensive (if at all); when comparing gcc 2.7 vs 2.95 the code generation improvements it triggers are in the noise. If you think -fstrict aliasing will make your kernel noticably faster, look at the above mentioned diff (and/or, even better, compare _your_ kernels w/ and w/o that optimization). otoh -fno-strict-aliasing gives you correctness guarantees that are almost impossible to give w/ __norestrict.
- 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/
| |