llvm dev - Nov 2016 - llvm optimizer turning musttail into tail

r287955 seems like it might be related.

-- Sean Silva

On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com>
wrote:
> This sounds buggy to me. What pass is doing this?
>
> -- Sean Silva
>
> On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> I've got some calls like:
>>
>> musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to void
>> (i32, i8*)*)(i32 %0, i8* %1)
>> ret void
>>
>> Into something like:
>> %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null)
>> ret void
>>
>> I realize I'm losing a parameter there, but this is an interface
jump
>> trick I use and relies on the end code being a 'jmp' (x86). I
realize i can
>> probably use noopt & noinline to do this trick, but I do want llvm
to
>> optimize and inline calls if it can prove it always calls a given
method.
>> Any way i can do this?
>>
>> --
>> Carlo Kok
>> RemObjects Software
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161126/d41676f1/attachment.html>

Inst combine yes. However it shouldn't drop this bit cast in the first
place, since the last parameter isn't available. (It only works because of
this must tail)

On 27 November 2016 01:37:43 CET, Sean Silva <chisophugis at gmail.com>
wrote:
>r287955 seems like it might be related.
>
>-- Sean Silva
>
>On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com>
>wrote:
>
>> This sounds buggy to me. What pass is doing this?
>>
>> -- Sean Silva
>>
>> On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>>
>>> I've got some calls like:
>>>
>>> musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to
>void
>>> (i32, i8*)*)(i32 %0, i8* %1)
>>> ret void
>>>
>>> Into something like:
>>> %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null)
>>> ret void
>>>
>>> I realize I'm losing a parameter there, but this is an
interface
>jump
>>> trick I use and relies on the end code being a 'jmp' (x86).
I
>realize i can
>>> probably use noopt & noinline to do this trick, but I do want
llvm
>to
>>> optimize and inline calls if it can prove it always calls a given
>method.
>>> Any way i can do this?
>>>
>>> --
>>> Carlo Kok
>>> RemObjects Software
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
-- 
Carlo Kok
RemObjects Software 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161127/9182590e/attachment.html>

Try using the "thunk" attribute:
http://llvm.org/docs/LangRef.html#function-attributes

InstCombine has logic to avoid getting rid of the cast in such situations:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineCalls.cpp#L2821



On Sun, Nov 27, 2016 at 7:40 AM, Carlo Kok <ck at remobjects.com> wrote:
> Inst combine yes. However it shouldn't drop this bit cast in the first
> place, since the last parameter isn't available. (It only works because
of
> this must tail)
>
>
> On 27 November 2016 01:37:43 CET, Sean Silva <chisophugis at
gmail.com>
> wrote:
>>
>> r287955 seems like it might be related.
>>
>> -- Sean Silva
>>
>> On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at
gmail.com>
>> wrote:
>>
>>> This sounds buggy to me. What pass is doing this?
>>>
>>> -- Sean Silva
>>>
>>> On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>>
>>>> I've got some calls like:
>>>>
>>>> musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod
to void
>>>> (i32, i8*)*)(i32 %0, i8* %1)
>>>> ret void
>>>>
>>>> Into something like:
>>>> %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null)
>>>> ret void
>>>>
>>>> I realize I'm losing a parameter there, but this is an
interface jump
>>>> trick I use and relies on the end code being a 'jmp'
(x86). I realize i can
>>>> probably use noopt & noinline to do this trick, but I do
want llvm to
>>>> optimize and inline calls if it can prove it always calls a
given method.
>>>> Any way i can do this?
>>>>
>>>> --
>>>> Carlo Kok
>>>> RemObjects Software
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>>
>>
> --
> Carlo Kok
> RemObjects Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161127/ed0c5a6f/attachment.html>

On Sun, Nov 27, 2016 at 7:40 AM, Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Inst combine yes. However it shouldn't drop this bit cast in the first
> place, since the last parameter isn't available. (It only works because
of
> this must tail)
>
Aside from instcombine, the inliner will also transform musttail to tail.
The supported use cases for musttail are essentially:
- Avoiding unbounded stack growth for programming languages that require
tail recursion
- Perfect forwarding of parameters which cannot be copied (think C++
objects constructed in argument slots, aka inalloca)
- Perfect forwarding for thunks which are called with varying signatures
(these effectively forward the ellipsis of the caller)

The last case sounds the most like yours, in which case David's suggestion
is the right one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161128/7fe89749/attachment.html>