lkml.org 
[lkml]   [2009]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning


On Mon, 12 Jan 2009, Linus Torvalds wrote:
>
> Type-based aliasing is unacceptably stupid to begin with, and gcc took
> that stupidity to totally new heights by making it actually more important
> than even statically visible aliasing.

Btw, there are good forms of type-based aliasing.

The 'restrict' keyword actually makes sense as a way to say "this pointer
points to data that you cannot reach any other way". Of course, almost
nobody uses it, and quite frankly, inlining can destroy that one too (a
pointer that is restricted in the callEE is not necessarily restricted at
all in the callER, and an inliner that doesn't track that subtle
distinction will be very unhappy).

So compiler people usually don't much like 'restrict' - because it i very
limited (you might even say restricted) in its meaning, and doesn't allow
for nearly the same kind of wild optimizations than the insane standard C
type-aliasing allows.

The best option, of course, is for a compiler to handle just _static_
alias information that it can prove (whether by use of 'restrict' or by
actually doing some fancy real analysis of its own allocations), and
letting the hardware do run-time dynamic alias analysis.

I suspect gcc people were a bit stressed out by Itanium support - it's an
insane architecture that basically requires an insane compiler for
reasonable performance, and I think the Itanium people ended up
brain-washing a lot of people who might otherwise have been sane.

So maybe I should blame Intel. Or HP. Because they almost certainly were
at least a _part_ reason for bad compiler decisions.

Linus


\
 
 \ /
  Last update: 2009-01-12 21:13    [W:0.216 / U:12.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site