On Tue, 19 Apr 2011, Jan Hubicka wrote: > > Huh. No, I don't think we want to do any "inlining" as part of > > folding. At least not if it > > is a correctness issue (is it?). Why does the inliner not simply > > inline the thunk function > > body? > > Because thunk functions have no bodies in gimple form and are no functions (at > the moment) in cgraph sense.
Well, I see thunks as simple forwarders which we can represent with a real function with body in gimple. We don't have to _emit_ it that way later, but at least IPA passes could do regular stmt analysis on them and not need any special thunk knowledge (maybe apart from making the inliner not inline the forwarding call into the thunk itself). > What IPA infrastructure needs to learn is to handle inlining of those as well > as compute proper jump functions. We spoke with Martin on this some time ago, > we ought to get this done in 4.7. Thunks are very irritating spcial cases from > cgraph POV ;( And I don't see why they have to be very irritating spcial cases ;) > I however like the idea that code doing devirtualizatio (type based or > folding based) > will also do adjustment to call the actual functions instead of thunk. Direct > calls to thunks are quite nonsential. Well, sure. If we discover a direct call to a thunk late, after inlining we can do some tricks to inline the adjustment, even during folding. Just analysis passes should simply see the thunk. Richard.
