search for: getelementpointer

Displaying 20 results from an estimated 37 matches for "getelementpointer".

2014 May 23
2
[LLVMdev] RFC: Indexing of structs vs arrays in 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...
2012 May 04
0
[LLVMdev] Extending GetElementPointer, or Premature Linearization Considered Harmful
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 *
2012 May 04
0
[LLVMdev] Extending GetElementPointer, or Premature Linearization Considered Harmful
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). > >
2012 May 04
3
[LLVMdev] Extending GetElementPointer, or Premature Linearization Considered Harmful
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
2014 May 22
2
[LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer
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
2012 May 04
3
[LLVMdev] Extending GetElementPointer, or Premature Linearization Considered Harmful
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
2014 May 22
4
[LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer
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
2010 Jun 04
0
[LLVMdev] Heads up: Local register allocator going away
...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)
2010 Jun 03
2
[LLVMdev] Heads up: Local register allocator going away
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
2008 Dec 30
7
[LLVMdev] Suggestion: Support union types in IR
...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...
2013 Feb 20
2
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...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...
2008 Aug 05
3
[LLVMdev] Anderson's analysis, getresult instruction on x86_64
...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:...
2008 Dec 31
0
[LLVMdev] Suggestion: Support union types in IR
...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...
2013 Feb 20
0
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...; 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...
2013 Jul 30
0
[LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI
...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...
2013 Feb 20
0
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...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...
2013 Feb 20
1
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
...> > > 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...
2008 Aug 11
2
[LLVMdev] Casting between address spaces and address space semantics
...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...
2009 May 06
2
[LLVMdev] Suggestion: Support union types in IR
...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...
2009 May 08
3
[LLVMdev] Suggestion: Support union types in IR
...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...