similar to: [LLVMdev] extractvalue and insertvalue on vector types

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

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

I've attached the module->dump() that our code is producing. Unfortunately this is the smallest test case I have available. This is before any optimization passes are applied. There are two separate modules in existence at the time, and there are no guarantees about the order the surrounding code calls those functions, so there may be some interaction between them? There shouldn't

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

Are you able to send any IR for others to reproduce this issue? On Wed, Jul 17, 2013 at 11:23 PM, Peter Newman <peter at uformia.com> wrote: > Unfortunately, this doesn't appear to be the bug I'm hitting. I applied > the fix to my source and it didn't make a difference. > > Also further testing found me getting the same behavior with other SIMD > instructions.

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

Unfortunately, this doesn't appear to be the bug I'm hitting. I applied the fix to my source and it didn't make a difference. Also further testing found me getting the same behavior with other SIMD instructions. The common factor is in each case, ECX is set to 0x7fffffff, and it's an operation using xmm ptr ecx+offset . Additionally, turning the optimization level passed to

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 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 Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >

Hi all, I've been implementing some stuff that uses the new structs-as-firstclass values code. Apart from some implementation problems, I'm spotting a few structural problems that seem non-trivial to fix. In particular, now that structs are a first class values, the old way or returning multiple values is a bit confusing. The old way had a variable number of arguments to the return

On Apr 27, 2008, at 12:49 PM, Nick Lewycky wrote: > Chris Lattner wrote: >> On Apr 27, 2008, at 10:58 AM, Talin wrote: >> >>> I would certainly make use of this in my frontend. >>> >>> I suggest the names "getfield" and "setfield" for the two >>> operations, >>> >> >> I agree that

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continue to only

On Apr 27, 2008, at 10:58 AM, Talin wrote: > I would certainly make use of this in my frontend. > > I suggest the names "getfield" and "setfield" for the two operations, > I agree that 'get/insertvalue' are pretty generic, and am welcome to suggestions. Get/set *field* imply that this applies only to structs, but it also works with arrays. I would

Several instruction classes override getType() when the instruction always creates a particular type of value. For example, the result of insertelement is always a vector, so InsertElementInst overrides getType() to return a VectorType*. This makes perfect sense. However, ExtractValueInst and InsertValueInst override getType() to return a PointerType*, which does not make sense and is

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