similar to: [LLVMdev] Structure returns to-do or not-to-do?

On Oct 20, 2010, at 2:56 PM, roger roger wrote: > I notice that using the online demo, functions which return structures are converted to be void, and instead take an extra argument which is the a pointer to the returned structure, and the allocation is made by the caller. > Even declared, but undefined functions are converted like this, presumably this doesn't cause a problem during

On 20/10/2010 23:25, John McCall wrote: > On Oct 20, 2010, at 2:56 PM, roger roger wrote: >> I notice that using the online demo, functions which return >> structures are converted to be void, and instead take an extra >> argument which is the a pointer to the returned structure, and the >> allocation is made by the caller. >> Even declared, but undefined

On Tue, Mar 2, 2010 at 2:34 AM, Dan Gohman <gohman at apple.com> wrote: > If you're wondering what this limit is, you're probably heading down > the wrong path, unless you're ultimate interest here is to work on > optimizer techniques for transforming this kind of code into > something usable. No, I'm just trying for correctness -- most of the time, only small

I’m using the C API (with a few additions in a single cpp file) to write a compiler. In one part of my code, I want to build a function that returns a structure. The LLVM Assembly Language Reference Manual gives this as a possible return value: > ret { i32, i8 } { i32 4, i8 2 } Meanwhile, compiling this C function: > Range make_range(Index location, Index length) { > return (Range){

Dear All, LLVMdev just got SPAM from roger83 at hotmail.co.uk. Please do not click on any of the links in that email. I've unsubscribed and banned this email address from llvmdev. Roger Roger is Banned Banned. -- John T.

Hi, Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Rob, > I’m using the C API (with a few additions in a single cpp file) to write a compiler. In one part of my code, I want to build a function that returns a structure. The LLVM Assembly Language Reference Manual gives this as a possible return value: > >> ret { i32, i8 } { i32 4, i8 2 } > > Meanwhile, compiling this C function: > >> Range make_range(Index

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 Monday 23 February 2009 16:14:57 Arnold Schwaighofer wrote: > The problem has to do with how struct returns are represented > internally by llvm (in the SelectionDAG) and how the tail call > optimization implementation checks if it may perform the tail call. > The implementation checks that the <call> node is immediately followed > by a <ret> node. A struct return

Now that we can safely return arbitrarily large structs on x86, it seems to me that fastcc, which doesn't have to conform to any preexisting ABI, should use ECX as well as EAX and EDX for returning {i32,i32,i32} rather than use sret-demotion. Any objections?

On Mon, Feb 23, 2009 at 2:13 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Moreover, I now have evidence that LLVM is not behaving as you expect: > > 3. Adjusting the return value from this function into sret form results in > tail call elimination being performed correctly. Note that this is still > passing a first-class struct by value as an argument to a function

I'm new to using LLVM and I've started work on a compiler for a language that can interface with C. One thing that caught me off guard was returning a struct from a function by value. It seems that when calling a C function I need to emit llvm ir that, in the caller, emits an alloca for the returned structure, and the C function signature should return void and take a first argument with

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

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

On Thu, Mar 28, 2013 at 8:22 AM, Joe Groff <arcata at gmail.com> wrote: > On Wed, Mar 27, 2013 at 8:15 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> This is why I suggest that the Windows ABI is whatever MSVC happens to >> do. The mingw ABI happens to consist of a conjunction of what MSVC does for >> C and what GCC on Linux does for C++. That is a

On Wed, Oct 07, 2015 at 04:35:10PM -0700, Tim Northover wrote: > > That seems to make it a pretty good case for consider sret mandatory in > > general. > > (Still) no more than any other type cast IMO. If you know what you're > doing you can cast function pointers (at the LLVM level), otherwise > you're going to get into trouble. I think we are talking about two

Hi, all When I compile the C code containing the next statement to LLVM, *struct A const o = func(...);* I got the next corresponding LLVM bytecode *call void @func(%struct.A* noalias sret %o, ...)* Could you tell me why function "func" with a return value is changed to be one with a void return value and another more parameter %o. Does "noalias sret" play a special role?

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