On Tue, 19 Apr 2011, Jan Hubicka wrote:
> > 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 is true only for non-variadic thunks. (and we actually generate bodies
> for
> those early, unless target asked us to do otherwise). Sure, Diego once
> mentioned that we might have some kind of special thunk_call gimple statement,
> but that seems to me that amount of gimple code that would need to handle
> thunk_call strictly exceeds amount of IPA code that would need to get past
> special kind of functions.
>
> Also as as we make them regular functions, we need to go all the way through,
> as IPA optimizers will happily modify them so simply using existing target
> interface instead of cfgexpand later won't help. In a way, with tailcall
> support, the target interface is really only interesting for variadic case.
> At least for i386. I did not inspect details of implementation of thunks on
> all the archs that do asm thunks to be sure.
>
> > 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 ;)
>
> Well, becuase of variadic thunks, I think ;)
I thought the idea was to use __builtin_va_arg_pack and friends.
Of course the inliner would still need to know how to inline such
a va-arg forwarder, and we would need a way to expand them (well,
or just go the existing special casing). We might need this
kind of inliner support anyway because of the partial inlining
opportunity in libquantum which is for a varargs function like
void foo (...)
{
if (always-zero-static)
return;
...
}
thus partial inlining would create such a forwarding call.
But well, it's just my random 2 cents on the issue ;)
Richard.
