similar to: [LLVMdev] (GEP) Index validity

Hi all, I just found that TargetData also contains a similar assert, and that I forgot a "return" in my previous patch. Here's an updated patch, which allows to use any integer to index a CompositeType. It seems this enables GEP to work with any integer value as well, I tested indexing a struct with a i16 an i64 (also through llc). This should still be adressed somewhere, unless we

Hi all, any comments about this patch? I'd like to get it out of my working copy :-) Gr. Matthijs > Index: lib/VMCore/Type.cpp > =================================================================== > --- lib/VMCore/Type.cpp (revision 53136) > +++ lib/VMCore/Type.cpp (working copy) > @@ -394,9 +394,8 @@ > > bool StructType::indexValid(const Value *V) const { >

I don't think this is right. According to llvm documentation: The index types specified for the 'getelementptr' instruction depend on the pointer type that is being indexed into. Pointer and array types can use a 32-bit or 64-bit integer type but the value will always be sign extended to 64-bits. Structure and packed structure types require i32 constants. Evan On Jul 10,

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

Hi all, currently, GetElementPtrInst has a method getIndexedType, which has a templated variant. You pass in a begin and an end iterator, and it will find the indexed type for those. However, both iterators must iterate over Value*. For some argpromotion code, I would like to pass in iterators that iterate over unsigneds instead of Value*. I currently solve this by transforming my

Hi Chris, > What flavor of iterators do you want to pass in? vector or > smallvector? If so, a pointer to the first element + extents is fine. I was passing a std::vector in. And you are quite right, first element + size works like a charm. Since I am using a vector of uint64_t's instead of Value*, I did need to add an extra version of getIndexedType(), taking a uint64_t* instead

On Jul 22, 2008, at 11:54 PM, Matthijs Kooijman wrote: > Hi Chris, > > >> I'd prefer to not turn this into a template. Why not just define a >> version that takes an array of uint64_t's or something like that? > because I want to be able to pass in iterators. I could define a > version that > takes std<uint64_t>::iterators, but next thing we know, we

> Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ > zero extension instructions. > > Does this actually affect the code being generated in practice? Inserting sign/zero extension instructions actually do tend to increase the generated code pretty dramatically on our target. So I prefer option (1) Does this change have dramatic affect on LLVM IR? PS. Currently

> I realize that sign extensions have non-zero impact when they exist in > the .s file. My assertion is that these will be zapped by the dag > combiner. Have you actually tried this? Yes, I have and they work just fine for us. I misunderstood your first email, I thought you are pointing at a problem, while you are actually saying that there is no problem. So back to my original

What is the reason for getelementptr being tied to only 32 or 64 bit indexes? It seems to me that integer size would be better choice... Anyways, this is getting in our way. What is your suggestion? Thanks Ali > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Chris Lattner > Sent: Monday, August 18, 2008 4:33

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into

Hi all, once more with the patch inline for easy review. I did not include the argpromotion pass here, since it's not the main topic of this post. Gr. Matthijs Index: lib/VMCore/Instructions.cpp =================================================================== --- lib/VMCore/Instructions.cpp (revision 53672) +++ lib/VMCore/Instructions.cpp (working copy) @@ -1068,41 +1068,6 @@

On Aug 18, 2008, at 4:20 PM, Alireza.Moshtaghi at microchip.com wrote: > This method is defined in: > Lib/VMCore/Type.cpp > And it makes hard assumption that size of integer is 32 or 64. > This gives us trouble because we have 16 bit integer. > Is there a reason for this assumption? Or we can just add the 16-bit > integer to it as well? Hi Alireza, The reason for this is that

This method is defined in: Lib/VMCore/Type.cpp And it makes hard assumption that size of integer is 32 or 64. This gives us trouble because we have 16 bit integer. Is there a reason for this assumption? Or we can just add the 16-bit integer to it as well? Thanks Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology

On Aug 19, 2008, at 6:54 AM, Alireza.Moshtaghi at microchip.com wrote: > What is the reason for getelementptr being tied to only 32 or 64 bit > indexes? As usual, the answer is "that is all anyone has needed so far" :) > Anyways, this is getting in our way. What is your suggestion? Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ zero extension

On Aug 19, 2008, at 4:14 PM, Alireza.Moshtaghi at microchip.com wrote: >> Two options: 1) change LLVM IR to allow it, or 2) just insert sign/ >> zero extension instructions. >> >> Does this actually affect the code being generated in practice? > > Inserting sign/zero extension instructions actually do tend to > increase > the generated code pretty

Please review this patch for PR3510 (and <rdar://problem/6564697>). The bug is a failure to handle a "hole" inside an initialized structure, where the hole may be induced by a designated initializer or by alignment: http://llvm.org/bugs/show_bug.cgi?id=3510 The original code was greatly simplified by using FieldNo to index the LLVM fields and the initializer in

Hi Chris & Evan, On Sun, Jul 13, 2008 at 03:34:03PM -0700, Chris Lattner wrote: > Why? What value does that provide? Struct indices are not allowed to > be variable, so picking any width constant (that isn't too small) is > fine. What problem are you trying to solve here? The current code only allows 32 bit constants. My patch allows any width constant to be used, but it

I really can't figure out how to get and set array indices from the c interface. so to get an element I'm calling tindex = *fn\SymbolTable(*index\name) index = LLVMBuildLoad(builder,tindex,"index") arr = *fn\SymbolTable(*array\name) arrptr = LLVMBuildLoad(Builder,arr,"arrayptr") tmp = LLVMBuildGEP(Builder,arrptr,index,0,"ptr") ptr =

Was hoping it might get some help or a better explanation of this: /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64