[llvm-dev] llvm optimizer turning musttail into tail

[David Majnemer via llvm-dev]

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>