similar to: musttail & alwaysinline interaction

It makes sense that you would be able to do this: %save1 = llvm.coro.save() %unused = musttail call llvm.coro.resume(%some_handle) %x = llvm.coro.suspend() ... But the docs for musttail say: > The call must immediately precede a ret instruction, or a pointer bitcast followed by a ret instruction. Should this be amended to allow a musttail to be followed by llvm.coro.suspend() ? Regards,

Hi, There is a problem with the handling of alwaysinline functions in Clang: they are not always inlined. AFAIK, this may only happen when the caller is in the dead code, but then we don't always successfully remove all dead code. Because of this, we may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler

On Thu, Aug 20, 2015 at 7:17 PM, John McCall <rjmccall at apple.com> wrote: > > On Aug 20, 2015, at 5:19 PM, Evgenii Stepanov via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi, > > > > There is a problem with the handling of alwaysinline functions in > > Clang: they are not always inlined. AFAIK, this may only happen when > > the caller is

On 09/23/2015 08:48 AM, Akira Hatanaka wrote: > On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > To be clear, this is a debuging aid only? It's not something > required for correctness? I'm somewhat bothered by that because > it seems like it would be a useful

I needed this functionality to solve http://llvm.org/PR20653, but it obviously has far more general applications. You can do it like this: define i32 @my_forwarding_thunk(i32 %arg1, i8* %arg2, ...) { ... ; define new_arg1 and new_arg2 %r = musttail call i32 (i32, i8*, ...)* @the_true_target(i32 %new_arg1, i8* %new_arg2, ...) ret i32 %r } declare i32 @the_true_target(i32, i8*, ...) The

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

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: >>

On 09/24/2015 01:47 PM, Akira Hatanaka wrote: > On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: >> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames >> <listmail at philipreames.com <mailto:listmail at

Hello! I've discovered that `CallSiteSplitting` optimization doesn't support musttail calls. The easiest fix as it stands is disabling it for such call sites: https://reviews.llvm.org/D43729 . However, I'm not happy with such contribution. My more sophisticated attempt has failed due to my poor understanding of llvm internals. Here is the attempted patch:

Hey Eli, On Thu, Feb 14, 2013 at 5:45 PM, Eli Bendersky <eliben at google.com> wrote: > Hello, > > While investigating one of the existing tests > (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some > interesting code. The IR is very straightforward: > > define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 > %a4) { > entry: >

Hello, While investigating one of the existing tests (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some interesting code. The IR is very straightforward: define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) { entry: ret i32 %a3 } define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { entry: %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32

>> While investigating one of the existing tests >> (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some >> interesting code. The IR is very straightforward: >> >> define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 >> %a4) { >> entry: >> ret i32 %a3 >> } >> >> define fastcc i32 @tailcaller(i32

To be clear, this is a debuging aid only? It's not something required for correctness? I'm somewhat bothered by that because it seems like it would be a useful implementation tool for higher level languages. A couple of thoughts in no particular order: 1) Can we always annotate the call site rather than the function? That removes the unpredictability due to optimization. 2) Calling

Update: I was able to make progress on it today ( See https://reviews.llvm.org/D43729 ). Apparently my problems were: * Iterating through the instruction/block list after erasing block/instruction * Trying to split block after removing one predecessor Regarding the latter, it appears that semantics of `DuplicateInstructionsInSplitBetween` change significantly in such case, and it starts to loop

When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of the stack. The caller cannot transitively know the tail callee's tailcallee's requirement. Also care must be taken to make sure the stack stays

Hi Arnold, Thanks for the insights. My comments below: On Thu, Feb 14, 2013 at 5:30 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of

Implementing tail call opt could look like the following: 0.)a fast calling convention (maybe use the current CallingConv::Fast, or create a CallingConv::TailCall) 1.) lowering of formal arguments like for example x86_LowerCCCArguments in stdcall mode we need to make sure that later mentioned CALL_CLOBBERED_REG is not used (remove it from available registers in callingconvention for

On 09/24/2015 03:04 PM, Akira Hatanaka wrote: > On Thu, Sep 24, 2015 at 1:53 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/24/2015 01:47 PM, Akira Hatanaka wrote: >> On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames >> <listmail at philipreames.com <mailto:listmail at

On Wed, Sep 18, 2019, 2:39 PM Steven Wu <stevenwu at apple.com> wrote: > > > On Sep 18, 2019, at 10:24 AM, Steven Wu <stevenwu at apple.com> wrote: > > Hi Dwight > > Thanks for the feedback. For the issue you reported, there has been few > reviews trying to tweak the -mllvm option when using legacy LTO interfaces > (myself included) but it never got enough

I think you realized this now, but to be clear: More likely, you've found some bugs. Unfortunately, not all of these utilities have good unit tests (though they should!). This would not be the first set of bugs people have found wrt to very start/end of blocks, or bb == predbb issues. On Sat, Feb 24, 2018 at 12:58 PM, Fedor Indutny via llvm-dev < llvm-dev at lists.llvm.org> wrote: