similar to: [LLVMdev] PSA: Perfectly forwarding thunks can now be expressed in LLVM IR with musttail and varargs

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

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

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

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

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

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

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:

Sure. One thing I want to remind you is that there is a place in Writer.cpp where we assume all synthetic sections were appended to end of Sections list. Look for `llvm::reverse`. If you add synthetic section thunks right before/after non-synthetic sections, you also want to change that. On Tue, Nov 29, 2016 at 1:18 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > >

Hi, Sorry for delay with reply. It looks like now thunks can be implemented as a synthetic sections. In that case we give flexible solution and will be able to put thunks before/after related sections, using different alignment etc. As far as I know BFD linker uses the same approach at least for MIPS thunks. I will try to implement this idea. On Thu, Sep 8, 2016 at 1:44 AM, Rui Ueyama <ruiu

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

Sometime this weekend (or today) vararg support will change. vanext will go away, and the intrinsic signatures will change. Backwards compatibility code will be included so front ends won't need to change initially (after that code is tested, then we will upgrade llvm-gcc). What should work after the transition: All Pattern based ISels (default on x86, PPC, Alpha, IA64) Existing .bc and .ll

Hi, I'm looking at writing a custom backend targetting a proprietary virtual machine. I'm basing it on the existing C and MSIL backends. The VM has a defined ABI for varargs functions: the caller allocates some memory to hold the arguments and passes a pointer to this memory as an extra parameter in the call. I'd like to write a varargs lowering pass that represents this ABI

Hi, After discussion with Anton, I did the whole thing in a little bit different way (please see the attached patch). It again looks like reinvented wheel for LLVM experts, I suppose, but it works. What I want to achieve is to generate real (with all variadic arguments) call signature for each variadic and external function, without the "vararg" keyword and without the "...",

I need to insert a varargs function declaration from within an LLVM pass. getOrInsertFunction() allows an arbitrary list of type parameters for function arguments to be passed in, but as far as I can tell there is no LLVM "type" to represent the variable-length portion of a function argument list. How is this normally done? --Patrick

I'm trying to use CallInst::Create to construct a call to a variadic function, and I'm running into the following assertion failure: /localhome/simmon12/workspace/llvm-sources/lib/VMCore/Instructions.cpp:297: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType())

On 6 April 2017 at 07:01, Peter Smith <peter.smith at linaro.org> wrote: > My understanding is that this would be (initially) limited to > fabricating enough linker script commands such that we could replace: > fixSectionAlignments() > assignAddresses() > Script->processNonSectionCommands() > > With something like: > Script->assignAddresses() // Could be done

This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously

On Thu, 13 Sep 2007, Jay Foad wrote: > Various parts of LLVM seem to assume that the ABI for a varargs > function is compatible with the ABI for a non-varargs function, so This is due to 'K&R' C function handling. In K&R and ANSI C, you can do stuff like this: void foo(); void bar() { foo(1, 2, 3); } void foo(int a, int b, int c) {} and it needs to work. > (I