similar to: [LLVMdev] Returning a structure

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 Duncan, Thanks for the response! > that's because clang is doing something more complicated than you are: it is > producing a function that conforms to the platform ABI for passing parameters. > The platform ABI specifies in this case that the valued should be returned via > a special in-memory mechanism (thus the "sret" extra function parameter) rather > than in

Unfortunately this is what I'm already doing, and it's not working. I drew inspiration from a disassembly of a program that showed that struct foo { int a; float b; char buf[80]; } struct foo get_foo(void) { foo f = { 5, 2.5 }; return f; } would turn into define void @get_foo(%struct.foo* sret %agg.result) nounwind ssp { ... call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8*

On Jul 23, 2008, at 9:05 AM, David Greene wrote: >> In the case of X86-64, llvm-gcc does use aggregate return (for the >> interesting cases which return things in registers) and it does do >> the > > I don't follow. By "aggregate return" do you mean "structs as first > class > values?" That is, llvm-gcc generates a return of a struct by

Hello, FYI, this is a bug http://llvm.org/bugs/show_bug.cgi?id=13324 When compiling the following code for sm_20, func params are by some reason given with .align 0, which is invalid. Problem does not occur if compiled for sm_10. > cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple =

On 6 nov. 07, at 06:17, Chris Lattner wrote: >> But then, why refuse aggregates as input or output of a call? What is >> the rationale? > > Because LLVM has no notion of aggregates as "values" that can be > passed around as atomic units. This is a very important design point, > and has many useful values. I see. You explained one of them in a message on the XL

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

Hi Rob, > Apologies in advance if this has been hashed over already—and of course, one should be aware that I know _absolutely nothing_ in this regard ( (: )—but perhaps at least some platform ABI details could be handled by an IR-to-IR transformation (a la one of the function passes), taking a function that returns some arbitrary structure via a return mechanism and changing it to use the

Hi all, in Rust we have a bug report about about a missed optimization which one would expect CallSlot optimization to handle: https://github.com/rust-lang/rust/issues/48533 The IR looks like this: define void @bar(%S* noalias nocapture sret dereferenceable(16), void (%S*)* nocapture nonnull) unnamed_addr #0 { %3 = alloca %S, align 8 %4 = bitcast %S* %3 to i8* call void

On Wednesday 23 July 2008 12:22, Chris Lattner wrote: > and both produce this machine code: > > _test: > movq (%rsi), %rax > movsd (%rdi), %xmm0 > ret Ok, that's good. > >> right thing. However, returning a {i64, i64, i64, i64} by value and > >> having it automatically be returned "by pointer" is less interesting, > > > > What do

I work with David Greene and I've been looking into the x86-64 ABI. Right now I'm working with the 2.3 release of LLVM and LLVM-GCC 4.2/2.3 (binary release for linux). I'm unable to replicate the results you posted here - I'm getting wildly different output. I wonder what I'm doing wrong. I suspect it has something to do with my not being able to pass it the -m64 or --64

Dear all, I'm attaching a patch that should fix the issue mentioned above. It simply makes the same check seen in the same file for global variables: emitPTXAddressSpace(PTy->getAddressSpace(), O); if (GVar->getAlignment() == 0) O << " .align " << (int) TD->getPrefTypeAlignment(ETy); else O << " .align " <<

On Dec 6, 2011, at 4:13 PM, Devang Patel wrote: > Hi Josh, > > On Dec 4, 2011, at 9:33 PM, Josh Matthews wrote: > >> I'm working on generating debug information for Rust, and I'm >> currently stumped on how to generate DWARF output via LLVM that will >> correctly represent this (eg. when exiting from foo2(), I'd like to >> see "Value returns

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 Fri, Jan 13, 2012 at 2:53 PM, Richard Pennington <rich at pennware.com> wrote: > Hi, > > I'm compiling lldiv.c from the NetBSD standard library. It works on ARM, Mips, > Microblaze,ppc, ppc64, and x86_64. On i386 a very strange thing happens. > Here's the source: > > #include <stdlib.h> > #define       __weak_alias(sym) __attribute__ ((weak, alias

Hi Duncan, On 11/10/12 15:47, Duncan Sands wrote: > Hi Roel, > >> When going through the internals of the old C back-end, I see that the CBE >> encapsulates arrays into a struct. The source code has the following comment to >> explain this behaviour. >> >> // Arrays are wrapped in structs to allow them to have normal >> // value semantics

On Thu, Oct 6, 2011 at 2:12 PM, Zeng Bin <ezengbin at gmail.com> wrote: > Hi all, > > There might be a bug in DeadStoreElimination.cpp. This pass eliminates > stores backwards aggressively in an end BB. It does not check dependencies > on stores in an end BB though. For example, in this code snippet: >   ... > 1.  %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre,

Hi all, There might be a bug in DeadStoreElimination.cpp. This pass eliminates stores backwards aggressively in an end BB. It does not check dependencies on stores in an end BB though. For example, in this code snippet: ... 1. %sum.safe_r47.pre-phi = phi i64* [ %sum.safe_r47.pre, %entry.for.end_crit_edge ], [ %sum.safe_r42, %for.body ] 2. %call9 = call i32 @gettimeofday(%struct.timeval* %end,

It does not do anything. It is an abstract function which transforms a pointer and returns another pointer of the same type. It does not visit memory or capture the pointer parameter. On Thu, Oct 6, 2011 at 2:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Oct 6, 2011 at 2:20 PM, Eli Friedman <eli.friedman at gmail.com> > wrote: > > On Thu, Oct 6, 2011 at

If int_guard_load returns a pointer based on the passed-in pointer, it captures it (at least according to the definition of "capture" which NoCapture uses). -Eli On Thu, Oct 6, 2011 at 2:26 PM, Zeng Bin <ezengbin at gmail.com> wrote: > It does not do anything. It is an abstract function which transforms a > pointer and returns another pointer of the same type. It does not