http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48674
--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-02 14:56:47 UTC --- (In reply to comment #8) > As discussed on IRC, the above patch is not really good idea. The consequence > of it is that the cgraph edges and IPA references will point to thunk nodes. > Those are not really nodes of callgraph and a idea of graph where edge targets > are not neccesarily its nodes is slipperly. > > I have patches to turn thunks to appear as function in cgraph that are > somewhat > ugly, but apparently less ugly from all alternatives we was able to come with. > My original plan was to first push cleanups to callgraph, but because the > whole > issue got escalated by the real world testcase, I will try to separate them > from rest of symtab code I have pending and push them to mainline soon. > > The weakest point of this approach is that thunks differ from usual functions > in several ways: > > 1) they don't have body representable in gimple (this is the case of variadic > thunks). This require changes at places where IPA passes want to analyze > function bodies: > > a) inliner must to know how to inline thunk (or to not inline it as I do as > a temporary hack) > b) inline-analysis needs to special case thunk function and guess their > size > c) ipa-prop needs to compute proper jump function for THIS > d) rest of IPA passes (pure-const/reference) are more or less trivial, > just need to avoid idea of looking into the function body since there > is nothing relevant for them anyway. Most of them is moot if we just accept that direct calls to thunks are a barrier for IPA optimizations (in the case they do not have a gimple body). We could represent variadic thunks in gimple using __builtin_va_arg_pack and friends if we accept the fact that we are never going to expand the gimple body from its stmts but instead from the usual mechanism of expanding such thunks. Whatever transformations we applied to the tunk body doesn't matter (they were just useless). > 2) they don't appear as function at ABI level and must be output in chunk with > the function they are attached. Similar to aliases (which, of course, also has ugly current handling). > 3) our RTL output machinery is somewhat convoluted. For thunks? Yeah. > the second two needs following changes I know of > > a) unreachable function removal must be weakened a bit on thunk functions > b) WHOPR partitioning must know that it always have to associate thunk > into every partition the thunked function comes to Similar to aliases. > c) cgraph_assemble_function Or rather expand. > My code bootstraps, but does not really work for i.e. Mozilla, so it is > entirely possible more side corners needs to be handled, too ;( So, indeed it sort-of makes sense to do symtab related changes first to get aliases implemented in a sane way. As thunks really need similar handling in a lot of places. Richard. > Honza
