http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48674
--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-05-02
14:55:38 UTC ---
Just to add, the other alternatives discussed were
I) Avoid direct calls to thunks at early optimization time.
This has problem with fact that C++ FE doesn't really tell us about thunks
in other units (though I think it has the knowledge) and thus this breaks
with LTO or if someone does direct call by hand (using aliasing ASM name
that
does not work at the moment in non-LTO compilation)
II) Invent Gimple representation of thunks
To do so, one would need to invent way represeting variadic thunks
Also either we would need to trash existing ASM thunk output machinery
and re-implement in a way so RTL optimizers produce same code expanding
the new construct.
Still we would need to handle same special cases for 1) and 2) from
my initial list of problems
III)Thunks are really meant to be alternative entry points to the functions.
We should eventually bite the bullet and implement them.
IV) Attach the info to edges. This makes things more transparent to WHOPR,
and most of ipa passes: i.e. if you don't care about it, you can pretend
thunks does not exist. It is also more consistent with III since
alternative
entry points should probably be represented as different kind of edges into
single callgraph node (=function).
It however seems to make less sense to people and makes it easier to
introduce wrong code bugs by ignoring the info on edges wehere you should
not.
