similar to: [LLVMdev] Pass a struct on windows

Hi Wei, this is a FAQ. The LLVM code generators do *not* try to produce ABI conformant code. Instead, your front-end must produce LLVM IR which is already ABI conformant. For example, on a platform where a function returning a struct should return it via a hidden pointer, the IR function should be declared with an explicit pointer argument for returning it; while on platforms for which it

Thanks for reply! This is indeed annoying. I suspect that passing an pointer to the struct and using GEP instructions to access and modify the struct would work on all platforms. Is this true? Thanks, Wei On Thu, Aug 11, 2011 at 7:55 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Wei, this is a FAQ. The LLVM code generators do *not* try to produce > ABI > conformant code.

Hi, When calling a function, does the llvm code generator support passing structured types (arrays, structs, etc.) by _value_? I wrote some small examples, and it seemed to work, but I was wondering if anything can go wrong if the structured types are very large... Thanks, N

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

On 8/4/2017 2:06 PM, Daniel Berlin wrote: > A few notes: > I'm a bit surprised IPO copy/constant propagation doesn't get this > case, but i didn't look if the lattice supports variables. > In particular, in your example, given no other call sites, it should > eliminate the dead code. > (In a real program, it may require cloning). In the actual program

Hi, Coincidentally I've been working to optimize this same case last week. I was struggling a bit to determine where to put this functionality and eventually went for the pragmatic approach of creating an experimental pass. Probably not the eventual solution, but it may provide some useful input to the discussion here. Basically, I experimented with a 'pre-inlining-transform' pass

On 8/7/2017 1:02 PM, Daniel Berlin wrote: > Can someone fill me in on the issue with the dominator tree, > precisely, during inlining? > We now have the capability of quickly keeping it up to date without > too much trouble (it may require pushing it through a bunch of places, > but the actual changes to do should be easy). If I'm not mistaken (which I very well could be

Hi All, I am a newbie to GPU programming. I wonder if anyone can help me with using GPU in .Call in R. Basically, I want to write a function that calcuates the sum of two double type vectors and implement this using GPU. My final goal is to make such an implementation callable from R. (a) First, I wrote a R-C interface handles the R object using .Call (saved as VecAdd_cuda.c

Hey everyone, I'm running stock LLVM 3.1 release. Both llc and opt programs have the -O# arguments, however it looks like the results are somewhat different. Here's a silly unoptimized bit of code which I'm generating from my LLVM-backed program ; ModuleID = 'foo' %Coord = type { double, double, double } define double @foo(%Coord*, %Coord*) nounwind uwtable ssp { entry:

On Oct 23, 2013, at 3:10 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 October 2013 16:05, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > In the examples you gave there are no reduction variables in the loop vectorizer’s sense. But, they all have memory accesses that are strided. > > This is what I don't get. As far as I understood, a

On 23 October 2013 16:05, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > In the examples you gave there are no reduction variables in the loop > vectorizer’s sense. But, they all have memory accesses that are strided. > This is what I don't get. As far as I understood, a reduction variable is the one that aggregates the computation done by the loop, and is used

Hi Tom, Matt, I'm running into strange issues with the cos test (piglit generated_tests/cl/builtin/math/builtin-float-cos-1.0.generated.c) I have been seeing random failures (incorrect results) for some time and tried to investigate. the weird part is that the failures are not 100% reproducible, sometimes the tests pass, or partly pass (it's usually float8 and float16 subtests that