similar to: RFC: Implementing the Swift calling convention in LLVM and Clang

> On Mar 2, 2016, at 1:33 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 March 2016 at 01:14, John McCall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, all. >> - We sometimes want to return more values in registers than the convention normally does, and we want to be able to use both integer and floating-point registers. For

> On Mar 2, 2016, at 11:33 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 2 March 2016 at 18:48, John McCall <rjmccall at apple.com> wrote: >> The frontend will not tell the backend explicitly which parameters will be >> in registers; it will just pass a bunch of independent scalar values, and >> the backend will assign them to registers or the stack

> On Mar 3, 2016, at 2:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 March 2016 at 20:03, John McCall <rjmccall at apple.com> wrote: >> We don’t need to. We don't use the intermediary convention’s rules for aggregates. >> The Swift rule for aggregate arguments is literally “if it’s too complex according to >> <foo>, pass it

> On Jun 2, 2020, at 4:21 PM, comex via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > While this is a different area of the codebase, another thing that > would benefit greatly from being moved out of Clang is function call > ABI handling. Currently, that handling is split awkwardly between > Clang and LLVM proper, forcing frontends that implement C FFI to > either

Hi Duncan. Duncan Sands <baldrick at free.fr> writes: >> define internal i1 @Addr_045442A0() { >> alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] >> alloca i1, align 4 ; <i1*>:2 [#uses=2] >> tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) > > this call uses the "struct-return" convention (due to the sret attribute). > On

> On Mar 3, 2016, at 10:06 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 3 March 2016 at 17:36, John McCall <rjmccall at apple.com> wrote: >> I’m not sure of your point here. We don’t use the Swift CC to call C functions. >> It does not matter, at all, whether the frontend lowering of an aggregate under >> the Swift CC resembles the frontend

Hi, > define internal i1 @Addr_045442A0() { > alloca [8 x i8], align 4 ; <[8 x i8]*>:1 [#uses=2] > alloca i1, align 4 ; <i1*>:2 [#uses=2] > tail call void @F95478DA5_FFI_FN( [8 x i8]* %1 sret ) this call uses the "struct-return" convention (due to the sret attribute). On x86 this means that the caller is responsible for adjusting the stack pointer after

On Oct 6, 2015, at 4:33 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 6, 2015 at 1:21 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Can you give an example of where it would trigger in LTO and when should > not? > > You could imagine that __muldc3 might be

When my llvm code calls certain function, either it receives a wrong result or the application ends on what it seems a corrupt stack. The function is a C++ static method that returns a class with just a `double' data member: class Foo { double data; }; My compiler abstracts this as a [8 x i8] array. This is the llvm code: define internal i1 @Addr_045442A0() { alloca [8 x i8], align 4 ;

Thanks for the explanation. It's good to hear the situation isn't felt to be ideal. The details here are going to be sensitive to the OS + target that I'm compiling for, right? So the effort here will be to understand and get right the calling convention details for each supported target, yes? Is there any current plan to change the way this works, or is it more of a dreamy cleanup

Oops, I neglected to reply-all…. The current stable branch at github still has it: https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> Should I get the head of the non-swift repository and generate a new diff? Also, I suspect that it’s not a good idea

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi Duncan, Karel, On 14 October 2011 08:22, Duncan Sands <baldrick at free.fr> wrote: > Hi Karel, > >>>> > const unsigned* >>>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>>> const { >>>> > + bool ghcCall = false; >>>> > + >>>> > + if (MF) { >>>> > + const

Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this

Dynamically Allocated "Callee Saved Registers" Lists Each Calling convention (CC) defines a static list of registers that should be preserved by a callee function. All other registers should be saved by the caller. Some CCs use additional condition: If the register is used for passing/returning arguments - the caller needs to save it - even if it is part of the Callee Saved Registers

On Mon, Oct 05, 2015 at 03:45:29PM -0700, Reid Kleckner wrote: > > > On 3 October 2015 at 02:29, Joerg Sonnenberger via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote: > > > > while debugging assertions when building libm for 32bit Sparc, I hit > > the > > > > following IR: > > > > > > > > complex_mul_libcall: >

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

What is the correct procedure for translating a function signature from a high-order language to LLVM? It looks like I replace each struct/array parameter with a 'byval' pointer parameter, and I replace a result struct/array with an 'sret' pointer parameter. The reason I ask is that each calling convention has subtle variations for each architecture and platform. For

Hello guys, Thanks for your help when you are busing. I am working on an open source project. It supports shader language and I want JIT feature, so LLVM is used. But now I find the ABI & Calling Convention did not co-work with MSVC. For example, following code I have: struct float4 { float x, y, z, w; }; struct float4x4 { float4 x, y, z, w; }; float4 fetch_vs( float4x4* mat

Hi David, > The code above is needed as the GHC calling convention redefines what > registers are considered callee save. No one else rummages in to the > original function as all the other calling conventions use the same > set of callee and caller save registers, so GHC is the only one that > needs to differentiate. shouldn't the caller also know what registers are callee