search for: getelementpointer

...r Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > > > > On Thu, May 22, 2014 at 5:54 PM, Louis Gerbarg < lgg at apple.com > > wrote: > > > > Hmm… you are correct, it turns out you are correct, I only have to > worry if it is constant after the second arg of the GEP. That should > all...

Hi Preston, On Fri, May 4, 2012 at 9:12 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > which produces > > %arrayidx24 = getelementptr inbounds [100 x [100 x i64]]* %A, i64 > %arrayidx21.sum, i64 %add1411, i64 %add > store i64 0, i64* %arrayidx24, align 8 > {{{(5 + ((3 + %n) * %n)),+,(2 * %n * %n)}<%for.cond1.preheader>,+,(4 *

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Duncan Sands wrote: >> As noted in the GEP FAQ, GEPs don't support variable-length arrays; > > that's not quite right. The problem is only with arrays of variable length > arrays, and more generally with arrays where the element type has variable > size (this occurs with Ada, which has all kinds of funky variable sized types, > for example). You're right, though

On May 22, 2014, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, May 22, 2014 at 4:42 PM, Louis Gerbarg <lgg at apple.com> wrote: > The problem that the above transform is technically illegal because “When indexing into a (optionally packed) structure, only i32 integer constants are allowed (when using a vector of indices they must all be the same

Is there any chance of replacing/extending the GEP instruction? As noted in the GEP FAQ, GEPs don't support variable-length arrays; when the front ends have to support VLAs, they linearize the subscript expressions, throwing away information. The FAQ suggests that folks interested in writing an analysis that understands array indices (I'm thinking of dependence analysis) should be

Recently I posted a patch to migrate certain GEPs between basic blocks in cases where doing so would improve the ability of instcombine to merge into more complicated addressing mode (r209049 and r209065). After some build to failures it was rolled back. I now have a patch that no longer causes the regressions I was seeing, but it also no longer can optimize the case I was trying to optimize. As

...ntptr [8 x [8 x float]]* %sl8_5, i64 0, i64 %idx, i64 0 %next = add i64 %idx, 1 %exitcond = icmp eq i64 %next, 8 br i1 %exitcond, label %Exit, label %Entry Exit: ret void } (Sorry for the cluttered simpification: removing any of the call, getelementpointer or loop removes the llc crash)

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

...d before), otherwise you get problems trying to mix pointer and non-pointer types. It seems to me that adding a union type to the IR would be a logical extension to the language. The syntax for declaring a union would be similar to that of declaring a struct. To access a union member, you would use GetElementPointer, just as if it were a struct. The only difference is that in this case, the GEP doesn't actually modify the address, it merely returns the input argument as a different type. In all other ways, unions would be treated like structs, except that the size of the union would always be the size of t...

...atible with BB vectorizer, and > whole bunch of code was removed… Interesting. > > Anyways, perhaps interesting parts for integrating to BBVectorizer > could be (crude) caching during replaceOutputs to be used when > vectorizing phi nodes. There is also some vectorization of > getelementpointer instructions, creation vectors of allocas to get > better vector memory accesses, some magic about computing addresses > of stride memory accesses using vectors, some tweaks to eliminate > unneeded shuffle instructions in replacement inputs etc. There are > lot of assumptions that the i...

...machine, it runs fine. I was trying to see if it is possible to quickly add a 'visitGetResultInst' to Andersons.cpp but could not quite find the right constraint to add to the pointer analysis. Can a instruction like : %mrv_gr = getresult { i64*, i64* } %74, 0 be modelled as a load/store/getelementpointer and a Constraint::Load/Store/Copy be added to handle this case ? Right now though, the opt crash in my case seems to be due to getresult that does not access pointers (i am guessing from {i64, i64} type though i may be wrong): $ opt -anders-aa < 175.vpr.bc >/dev/null Unknown instruction:...

...t;gep trick" won't work for type generation. > It seems to me that adding a union type to the IR would be a logical > extension to the language. The syntax for declaring a union would be > similar to that of declaring a struct. To access a union member, you > would use GetElementPointer, just as if it were a struct. The only > difference is that in this case, the GEP doesn't actually modify the > address, it merely returns the input argument as a different type. > In all other ways, unions would be treated like structs, except that > the size of the union w...

...; whole bunch of code was removed… > > Interesting. > >> >> Anyways, perhaps interesting parts for integrating to BBVectorizer >> could be (crude) caching during replaceOutputs to be used when >> vectorizing phi nodes. There is also some vectorization of >> getelementpointer instructions, creation vectors of allocas to get >> better vector memory accesses, some magic about computing addresses >> of stride memory accesses using vectors, some tweaks to eliminate >> unneeded shuffle instructions in replacement inputs etc. There are >> lot of assump...

...ypeWithCopyConstructor argn, int argp1...) You will need an alloca for argn, but the ABI also requires it to be next to the plain integers that didn' fit in registers, no? This is part of the reason my suggestion was to have a single opaque object representing the frame being constructed and a getelementpointer like abstraction to get pointers out of it. On 25 July 2013 17:38, Reid Kleckner <rnk at google.com> wrote: > Hi LLVM folks, > > To properly implement pass-by-value in the Microsoft C++ ABI, we need to be > able > to take the address of an outgoing call argument slot. This i...

...uming. So the candidate selection is not compatible with BB vectorizer, and whole bunch of code was removed… Anyways, perhaps interesting parts for integrating to BBVectorizer could be (crude) caching during replaceOutputs to be used when vectorizing phi nodes. There is also some vectorization of getelementpointer instructions, creation vectors of allocas to get better vector memory accesses, some magic about computing addresses of stride memory accesses using vectors, some tweaks to eliminate unneeded shuffle instructions in replacement inputs etc. There are lot of assumptions that the instructions to be ve...

...> > > Interesting. > > > >> > >> Anyways, perhaps interesting parts for integrating to BBVectorizer > >> could be (crude) caching during replaceOutputs to be used when > >> vectorizing phi nodes. There is also some vectorization of > >> getelementpointer instructions, creation vectors of allocas to get > >> better vector memory accesses, some magic about computing > >> addresses > >> of stride memory accesses using vectors, some tweaks to eliminate > >> unneeded shuffle instructions in replacement inputs etc. The...

...t;> this information: It removes any bitcasts from a subset to a superset >> address space. It gets at the address space information by requiring the >> TargetAddrspaces analysis, which will give it the default implementation in >> all current tools. > > For the case of a GetElementPointer, we are replacing a bitcast to a > pointer, getelem with a getelem bitcast. The assumption is the latter > bitcast will hopefully go away when we iterate through those uses. Uh? Is this a comment about what the current code or my patch does, or what it should do? I don't understand wha...

...t work for type generation. > > >> It seems to me that adding a union type to the IR would be a logical >> extension to the language. The syntax for declaring a union would be >> similar to that of declaring a struct. To access a union member, you >> would use GetElementPointer, just as if it were a struct. The only >> difference is that in this case, the GEP doesn't actually modify the >> address, it merely returns the input argument as a different type. >> In all other ways, unions would be treated like structs, except that >> the siz...

...t work for type generation. > > >> It seems to me that adding a union type to the IR would be a logical >> extension to the language. The syntax for declaring a union would be >> similar to that of declaring a struct. To access a union member, you >> would use GetElementPointer, just as if it were a struct. The only >> difference is that in this case, the GEP doesn't actually modify the >> address, it merely returns the input argument as a different type. >> In all other ways, unions would be treated like structs, except that >> the siz...