* Bernd Schmidt <bernds_...@t-online.de> wrote:
> Linus Torvalds wrote:
> > But you'll need some background to it:
>
> You paint a somewhat one-sided picture bordering on FUD.
>
> > Type-based aliasing is _stupid_.
>
> Type-based aliasing is simply an application of the language definition,
> and depending on the compiled application and/or target architecture, it
> can be essential for performance.
> [...]
>
> So, to summarize: strict aliasing works for nearly every application
> these days, there's a compiler switch for the rest to turn it off, it
> can be a serious performance improvement, and the compiler warns about
> dangerous constructs. That makes the issue a little less black and
> white than "type based aliasing is stupid".
i did some size measurements. Latest kernel, gcc 4.3.2, x86 defconfig,
vmlinux built with strict-aliasing optimizations and without.
The image sizes are:
text data bss dec hex filename
6997984 1635900 1322376 9956260 97eba4 vmlinux.gcc.-fno-strict-aliasing
6985962 1635884 1322376 9944222 97bc9e vmlinux.gcc.strict-aliasing
that's 0.17% of a size win only.
The cost? More than _300_ new "type-punned" warnings during the kernel
build (3000 altogether, including duplicates that trigger in multiple
object files) - more than _1000_ new warnings (more than 10,000 total) in
an allyesconfig build.
That is a _ton_ of effort for a ~0.1% category win. Often in historic code
that has been working well and now got broken by gcc.
I think this feature has been over-sold while it under-performs. You also
significantly weakened the utility of the C language for lowlevel
hardware-conscious programming as a result (which is the strongest side of
C by far).
Type based aliasing should at most have been an opt-in for code that
cares, not a turned-on-by-default feature for everyone.
You already dismissed concerns in this thread by suggesting that Linux is
just one of many projects, but that way you dismiss 1) the largest OSS
project by linecount 2) one of the most performance-optimized pieces of
OSS software in existence.
I.e. you dismiss what should have been GCC's strongest supporter, ally,
test-field and early prototype tester. A lot of folks in the kernel look
at the assembly level on a daily basis, they run the latest hardware and
they see where GCC messes up. By dismissing Linux you cut yourself off
from a lot of development power, you cut yourself off from a lot of
enthusiasm and you miss out on a lot of dynamism that would naturally help
GCC too.
I.e. almost by definition you cannot possibly be interested in writing the
best compiler on the planet.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
