search for: extractvalues

I'm writing a front end for an existing interpreted language with slightly odd semantics for primitive values. Similar to the values in a database table, any value could be null, even for non-pointer types. For example a boolean variable could be true, false, or null. To model this behaviour, I'm passing an {i1, [type]} around for every numeric type. And using insertvalue / extractvalue

Hi, I'm working with some hand-written LLVM IR which llvm-as doesn't like, giving me the error "Invalid indices for extractvalue". However, as far as I can tell, the code is valid according to the Language Reference Manual. A cut-down example of the kind of code in question is: %struct.s = type {i32,i32,<2 x i32>} define void @entry(i32* %out) { %1 = extractvalue

Hi Can someone explain to me why we cant use uint64_t for extractvalue and insertvalue indices, while GEP on arrays can have indices of any integer type. Basically if I load an array with UINT_MAX+O (O>=2) elements, I can not extract its last element. Given this restriction I feel we have a bug here (uint64_t is passed as a unsigned). This cant happen because of the if (NumElements > 1024)

Hi Andrew, > If I change the code such that the structure is defined with a > 2-element array instead of a 2-element vector: > %struct.s = type {i32,i32,[2 x i32]} > then llvm-as does not report an error, hence why I believe the problem > is specific to accessing vector components. correct, extractvalue doesn't work on vectors, you need to use to use extractelement for

Hi, The 'extractvalue' and 'insertvalue' instructions only allow constant indices. If I have an array with variable indices, I need to store it into memory, and then load its sub-elements via GEP. Why could 'extractvalue' not support variable indices like GEP? In general, in which case should source code be translated into 'extractvalue' , and when should

> > On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: >> I'm toying with benchmarks on my HLVM and am unable to get any >> performance >> improvement from optimization passes... > > I just disassembled some of the IR before and after optimization. > This example > function squares a complex number: Something is definitely wrong with the way

I'm having an issue where a certain set of types and insert/extractvalue are producing the incorrect values. It appears as though extractvalue getting my sub-structure is not getting the correct data. I have these types: %outer = type { i32, %inner, i1 } %inner = type { double, i32 } The trouble is that when I have a value of type %outer then proceed to extract the components of the

Hi all, sorry to have sent the same question around. I am quite desperately looking for a solution to this problem and I figured the mailing list is the best bet. In my code, I generate the following function: define i32 @gl.qi([500 x i32] %x, i32 %i) { entry: %x. = alloca [500 x i32] %i. = alloca i32 %0 = alloca [500 x i32] store [500 x i32] %x, [500 x i32]* %x. store i32 %i, i32*

[Adding the correct cfe-dev mailing list address.] On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > Now that ASM goto support has landed, Nick Desaulniers and I wrote up a > document describing how to expand clang's implementation of ASM goto to > support output constraints. The work *should* be straight-forward, but as > always will need to

On Apr 25, 2014, at 2:21 PM, Eric Christopher <echristo at gmail.com> wrote: >> In short, I agree with your observations that these intrinsics are not an >> obvious slam-dunk compared to making the explicit control flow, but I think >> that the intrinsics do give enough flexibility on the LLVM side that it >> would be great if front-ends used them rather than rolling

Hi all, I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. If I have some sequence (> 1) of llvm.*.with.overflow.* intrinsics, as in the form of: @global = global i32 0

Tim Northover <t.p.northover at gmail.com> writes: > On Mon, 1 Jul 2019 at 19:56, David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> llvm.creal.* - Overloaded intrinsic to extract the real part of a >> complex value >> declare float @llvm.creal.c32(c32 %Val) >> declare double @llvm.creal.c64(c64 %Val) > > What are

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

Hi, Integer overflow checks often use divisions, which may hurt performance. See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Here's a prototype implementation of two passes that complement -instcombine. They recognize common checking patterns and rewrite them using overflow intrinsics. https://gist.github.com/3429064 https://gist.github.com/3429069 Here goes an example.

I also saw this issue before. Llvm seems have trouble returning general struct values from functions. One easy workaround is to use packed struct type. Hope this helps. -Peng On Sunday, December 30, 2012, edA-qa mort-ora-y wrote: > I'm having an issue where a certain set of types and insert/extractvalue > are producing the incorrect values. It appears as though extractvalue >

+ CBL mailing list On Thu, Jun 27, 2019 at 11:08 AM Bill Wendling <isanbard at gmail.com> wrote: > [Adding the correct cfe-dev mailing list address.] > > On Thu, Jun 27, 2019 at 11:06 AM Bill Wendling <isanbard at gmail.com> wrote: > >> Now that ASM goto support has landed, Nick Desaulniers and I wrote up a >> document describing how to expand clang's

I am very much in favor of having a div instruction with well defined div-by-zero and overflow behavior. The undefined behavior on certain values for LLVM intrinsics has been a major pain point for us in Julia, because adding the extra branches just kills performance and we know that there is an X86 instruction that just does what we want. Anyway, this was brought up briefly above, but want to

I've run into cases where, because not all of LLVM's optimizations understand the semantics of the `llvm.$op.with.overflow` intrinsics, canonicalizing compares to `llvm.$op.with.overflow` ends up preventing optimization. For instance, running the following snippet through `opt -indvars` optimizes `%to.optimize` to `true`, but running it through `opt -instcombine -indvars` does not. ```

On May 19, 2010, at 7:07 AM, o.j.sivart at gmail.com wrote: > Hi all, > > I'm interested in the impact of representing code via intrinsic functions, in contrast to via an instruction, when it comes to performing dead instruction/code elimination. As a concrete example, lets consider the simple case of the llvm.*.with.overflow.* intrinsics. > > If I have some sequence (> 1)

I was playing with optimization switches to llc to see how fast I could get it to compile but it keeps barfing. Tinkering indicates that llc barfs particularly when -tailcallopt is given in combination with other flags. For example, without -tailcallopt works in a couple of ways: $ llc -O0 -f aout.bc -o aout.s $ llc -O0 --regalloc=local -f aout.bc -o aout.s But fails with -tailcallopt with