[llvm-dev] llvm optimizer turning musttail into tail

Carlo Kok via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 27 07:40:30 PST 2016


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>


More information about the llvm-dev mailing list