[llvm-dev] Get llvm to optimize through thunk method

[Carlo Kok via llvm-dev]

On Thu, Oct 4, 2018, at 20:53, Friedman, Eli wrote:
> On 10/4/2018 11:14 AM, Carlo Kok wrote:
> >
> > On Thu, Oct 4, 2018, at 20:05, Friedman, Eli wrote:
> >> On 10/4/2018 1:58 AM, Carlo Kok via llvm-dev wrote:
> >>> Hi,
> >>>
> >>> is there a way I can tell llvm to optimize through a call to a thunk method?
> >>>
> >>> https://gist.github.com/carlokok/3ba9cb1a36a145a3071a7b901867d442
> >>>
> >>> On line 37 I cast & call _intf__rtti_t27_issue81139__static__dispatchtest_d_Test_vmthelper0
> >>>
> >>> which is a thunk method that calls
> >>> _intfstub_mi_t27_issue81139__static__dispatchtest_d_Test4_Test
> >>>
> >>> Is there a way to tell the optimizer to get rid of the thunk call? Since llvm can prove it will end up in _intfstub_mi_t27_issue81139__static__dispatchtest_d_Test4_Test
> >>> given the parameters passed?
> >> LLVM is conservative if the callee of a call is bitcast in a non-trivial
> >> way; it treats the call as opaque.
> >>
> >> What are you trying to accomplish by passing the wrong number of
> >> arguments to the call?
> >>
> > The vmt helper does a tail call that acts like a thunk. The final method has the right number of parameters and I adjust the sig to match the calling convention. It's essentially a trick to do interface dispatch without requiring an explicit vmt per interface.
> 
> In addition to the inlining problem you've noted, defining the thunk 
> with too few arguments is likely to corrupt the remaining arguments.
> 
> I think you can avoid the issue with corrupted arguments by defining the 
> thunk using a varargs type.  But I don't think there's any existing 
> solution for your inlining issue.
>

Thnx. I'm not getting corruption so I'm good there. Was hoping for a solution to the in lining but that can't be helped.