similar to: [LLVMdev] const indices of 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, Some instructions are not implemented in the interpreter. For example, extractvalue, insertvalue, load/store aggregate pointers, bitcast between vectors and ints. Is this only the limitation of the current release? or is there any technical reason that the interpreter has to omit these instructions. -- Jianzhou

On Wed, Jul 14, 2010 at 6:05 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Some instructions are not implemented in the interpreter. For example, > extractvalue, insertvalue, load/store aggregate pointers, bitcast > between vectors and ints. Is this only the limitation of the current > release? or is there any technical reason that the interpreter has to > omit these

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

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

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

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

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 >

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

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

On Jan 12, 2010, at 5:01 PM, Talin wrote: > Here is the LangRef part of the patch. > +<p>The union type is used to represent a set of possible data types which can > + exist at a given location in memory (also known as an "untagged" > + union). [...] This wording is somewhat misleading; memory in LLVM has no types. How about: "A union type describes an

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept

On Jun 2, 2008, at 1:03 PM, Matthijs Kooijman wrote: >> Can you give some background about what kinds of things you're >> thinking >> about for this? > For example, when I have a function returning {i32, i32} and I want > to add > another i32 to that. If this was a function that simply returns two > i32 > values, any caller will only use extractvalue on

On Tue, 2 Jul 2019 at 19:11, Finkel, Hal J. <hfinkel at anl.gov> wrote: > One option is to make the complex type a special kind of vector, or a > special kind of aggregate (I have a slight preference for the latter). > That gives us an existing set of accessors. I agree non-vector. If nothing else a vector of complexes seems like a sensible concept which would be harder if a

On 01/20/2015 12:45 PM, Reid Kleckner wrote: > On Tue, Jan 20, 2015 at 9:52 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > 1) Larger structs are returned differently, via memcpy. Do > these methods of returning struct values show through in > the ultimately generated machine code? It seems hard to

While playing with SLPVectorizer, I notice that it will happily vectorize cases involving extractelement/insertelement, but won't vectorize isomorphic cases involving extractvalue/insertvalue (such as the attached example). Is that something that could be straightforward to add to SLPVectorizer, or are there some hard issue? In particular, the transformation would seem to require casts of

Hi. Version 0.5 of llvm-py, Python bindings for LLVM, has been released. This version supports (only) LLVM 2.4. New instructions of LLVM 2.4 (vicmp, vfcmp, insertvalue, extractvalue) are available. Home page: http://mdevan.nfshost.com/llvm-py/ Feedback welcome. Thanks & Regards, -Mahadevan.

On Apr 8, 2012, at 10:40 PM, Bill Wendling wrote: > What gets returned by the landingpad instruction (%0 here) is normally a structure. LLVM doesn't typically treat aggregates as first-class citizens. In particular, you shouldn't store the whole structure to memory like you do to %5. You can use 'extractvalue' to get the different elements of the structure. If you need to