similar to: [LLVMdev] Function Parameter Requirements?

Hi, > I'm trying to find the requirements for function parameters in the > documentation. The assembler rejects 'i32({i32,i32})' with the error > 'Function arguments must be value types!' so I'm guessing that each > parameter type must be a first-class type. they must be first-class types or opaque types. > The assembler also rejects >

Hello, In my LLVM frontend (CLR/MSIL), I am currently using first-class aggregates to represent loaded value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with

I am needing to return i128 as a shadow return due to abi issues on alpha.  The problem I am running into is the code for doing that with scalars (currently only used for vectors, as far as I can tell) sets the sret on the parameter.  If I just go this path, then I am setting sret on an integer pointer, which verify objects too.  LangRef doesn't say scalars are allowed to have sret set, but

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: > On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) >> and Anton kindly explained that LLVM is doing the right thing as per the >> ABI (the GCC ABI, I'll add). >> >>  1. Is there a LLVM way of

On Aug 19, 2010, at 1:38 PM, Andrew Lenharth wrote: > I am needing to return i128 as a shadow return due to abi issues on > alpha. The problem I am running into is the code for doing that with > scalars (currently only used for vectors, as far as I can tell) sets > the sret on the parameter. If I just go this path, then I am setting > sret on an integer pointer, which verify

On Fri, Sep 25, 2009 at 2:41 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > I filed a bug yesterday ( http://llvm.org/bugs/show_bug.cgi?id=5046 ) > and Anton kindly explained that LLVM is doing the right thing as per the > ABI (the GCC ABI, I'll add). > >  1. Is there a LLVM way of dealing with this without using separate code >  for VC++ and GCC? I'm not sure what

> 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

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx

I have these two instructions, first one inside some procedure, second one is an outside declaration. Code verification passes and it runs, but incorrectly. Every time I saw such situation coming from c++ compiler, attributes 'noalias sret' appear on both call and declaration. Does such situation make sense, or (as I guess it is) a bug in verifier? I think verifier should match at

> 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

Hi, all. Swift uses a non-standard calling convention on its supported platforms. Implementing this calling convention requires support from LLVM and (to a lesser degree) Clang. If necessary, we’re willing to keep that support in “private” branches of LLVM and Clang, but we feel it would be better to introduce it in trunk, both to (1) minimize the differences between our branches and trunk and

On Mon, Mar 1, 2010 at 7:39 PM, Reid Kleckner <rnk at mit.edu> wrote: > IIRC they lower it themselves, doing whatever the ABI says they > should, which is usually adding a hidden sret parameter to the > function once you get beyond small structs. Okay, so we seem to be saying sret or suchlike is how you pass and return large objects by value in LLVM. What exactly counts as large?

> 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

Hi all, I'm currently building a DSL for a computer graphics project that is not unlike NVIDIA's Cg. I have an intrinsic with the following signature float4 sample(texture tex, float2 coords); that is translated to this LLVM IR code: declare void @"sample"(%float4* noalias nocapture sret, %texture, $float2) nounwind readnone The type float4 is basically an array of four

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval)

On May 7, 2010, at 6:24 PM, Yuri wrote: > I have these two instructions, first one inside some procedure, second > one is an outside declaration. > Code verification passes and it runs, but incorrectly. Right, this code has undefined behavior. > Every time I saw such situation coming from c++ compiler, attributes > 'noalias sret' appear on both call and declaration.

On Tuesday 22 July 2008 01:23, Chris Lattner wrote: > David, I'm not sure I follow. It is, of course, very important for us > that llvm-gcc generate ABI compliant code on x86-64. I'm just saying > that if struct-return does not provide the ABI required for a specific > source construct that another lowering would be needed. Ah, ok. I misunderstood your statement. > In

On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <baldrick at free.fr> wrote: > On 29/07/13 15:30, Anton Korobeynikov wrote: > >> object in place on the stack or at least call its copy constructor. >>>> >>> >>> >>> what does GCC do? >>> >> Nothing. It does not support MSVC ABI. >> > > Maybe we shouldn't either :)

On Mon, Jul 29, 2013 at 10:45 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Reid, > > > On 29/07/13 16:36, Reid Kleckner wrote: > >> On Mon, Jul 29, 2013 at 9:40 AM, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> On 29/07/13 15:30, Anton Korobeynikov wrote: >> >> object

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is