search for: musttail

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

Consider this program: @globalSideEffect = global i32 0 define void @tobeinlined() #0 { entry: store i32 3, i32* @globalSideEffect, align 4 musttail call fastcc void @tailcallee(i32 3) ret void } define fastcc void @tailcallee(i32 %i) { entry: call void @tobeinlined() ret void } attributes #0 = { alwaysinline } Clearly, if this is processed with opt -alwaysinline, it will lead to a correct tail call since the call to "tobeinl...

...solution. > > I also feel like passing -tailcallopt in the linker stage is kind of > fragile. It is better to create an attribute (on function or callInst) to > force tailcallopt and some compiler flag to generated that during IRGen. > > > I think I missed you comments about `musttail`. Do you have any example to > show why `musttail` doesn’t work for you? Is there anything we can do to > make it work so we don’t need to rely on `-mllvm` options? > > Steven > The problem with musttail is that the behavior of the feature is that IR does not verify if it includes a...

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

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 varargs convention (usually) matches the standard function call convention, and everything will line up if you do an indirect call like this: declare i32 @t...

...hisophugis 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 the...

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: https://gist.github.co...

...at the original block becomes empty. Is it expected behavior, or am I doing something wrong? Thanks, Fedor. On Sat, Feb 24, 2018 at 2:16 AM, Fedor Indutny <fedor at indutny.com> wrote: > 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...

Hi, On 27/02/2018 16:32, Daniel Berlin via llvm-dev wrote: > 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. >

...expected behavior, or am I doing something wrong? > > Thanks, > Fedor. > > On Sat, Feb 24, 2018 at 2:16 AM, Fedor Indutny <fedor at indutny.com> wrote: > >> 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...

On 8 Oct 2014, at 18:19, Reid Kleckner <rnk at google.com> wrote: > The one target I know about where varargs are passed differently from normal arguments is aarch64-apple-ios/macosx. After thinking a bit more, I think this forwarding thunk representation works fine even on that target. Typically a forwarding thunk is called indirectly, or at least through a bitcast, so the LLVM IR call

...ctions that call themselves would probably cause a lot of problems, including stack overflows, for code written in our programming language. Recursion is basically the only way to loop in most functional languages; that's why the tailcallopt flag was created. > > > We can't use `musttail` because the callee and caller often have different signatures. > > We would like to support link time optimization in our programming language, because performance is important to us. However, there is no clang flag to enable the GuaranteedTailCallOpt flag, and the only way to pass target o...

...timization. > > > Annotating the call site should be fine. For the use cases that we > care about, it probably isn't important to prevent tail calls on > indirect calls. Given this, I would lean towards a notail value being added as an alternative to "tail" and "musttail". This seems to fit the existing uses, doesn't have any obvious loop holes or best effort semantics, and solves the problem at hand. > > 2) Calling it something like "no-direct-tail-call" or > "prefer-no-tail" would remove some of the confusion value...

...frontends have to enable the GuaranteedTailCall codegen option and obey a narrow set of rules, which includes always using fastcc. This is fairly awkward and doesn't solve my use case, since the ABI requires a particular convention. Instead, I propose that we add a new tail call marker, 'musttail', that guarantees that TCO will occur. I'm open to other naming suggestions. Some strawmen are 'tailonly' or 'guaranteedtail'. Along with it, I propose a set conservative of verifier enforced rules to follow to ensure that most reasonable backends will be able to perform...

...ords, this change would add a new attribute that marks a very > specialized kind of function and an intrinsic that can only occur in this > kind of function. > > What do you think? I think you might be close. The llvm.jumptable.instr intrinsic you have proposed is similar to the 'musttail' call marker that Reid (cc'd) is working on in [1]. That marker will also have verifier support. I think it might be reasonable to require the code generator to emit the body of a function containing only a 'musttail' function call as a single branch instruction. Then you could emit...

...tating the call site should be fine. For the use cases that >> we care about, it probably isn't important to prevent tail calls >> on indirect calls. > Given this, I would lean towards a notail value being added as an > alternative to "tail" and "musttail". This seems to fit the > existing uses, doesn't have any obvious loop holes or best effort > semantics, and solves the problem at hand. >> >> 2) Calling it something like "no-direct-tail-call" or >> "prefer-no-tail" would...

...M by creating a special calling convention which >> forces a function (using this convention) to pass args in registers and to >> be force tail-call optimized. > You absolutely will need a custom calling convention for the register > assignments and such. If your source IR uses musttail, in principal you > shouldn't need to do anything special for the tail calls provided you're > running on one of the architectures where musttail has been implemented. musttail has some limitations (ex., the caller and callee prototypes must match), but tail with -tailcallopt work...

...il, the basic elements of the virtual call mechanism are described in 'Invokeinterface Considered Harmless' [2] (albeit for Java). ---- Encoding calls in LLVM IR ---- Encoding this information in LLVM IR seems to be very difficult, albeit I've noticed some recent developments (such as musttail) that could be useful for this. There was a previous discussion of this issue in 2011 [3] and the conclusion seemed to be that the mechanism above couldn't be encoded in LLVM IR. It is possible to generate the necessary inline assembly, but then LLVM has no knowledge of the function calls and...

...ve to inter-operate with legacy code and are not flexible on how %method_id is propagated (i.e. it _has_ to be in %eax) then a custom calling convention that puts the first argument in %eax is probably the best way to go. > As for forwarding arguments, it seems like the combination of > 'musttail' and varargs come close to satisfying this. The only issue > is that it's not possible to forward a return value. I'm not sure I understand what you mean by "forward a return value", but running the following: declare i32 @f(i32, i64) define i32 @conflict_resolution_stub...

...ine. For the use cases >>> that we care about, it probably isn't important to prevent >>> tail calls on indirect calls. >> Given this, I would lean towards a notail value being added >> as an alternative to "tail" and "musttail". This seems to fit >> the existing uses, doesn't have any obvious loop holes or >> best effort semantics, and solves the problem at hand. >>> >>> 2) Calling it something like "no-direct-tail-call" or >>>...