The difference is that %x would be just a generic pointer type, but the type would still need to be supplied as an argument to the GEP / load / store. %inner.ptr = getelementptr i8**, %x, i32 1 You could think of it as having an implicit bitcast on every pointer operation. On Sat, Feb 7, 2015 at 10:42 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:> How would GEP's look like in this scheme? Concretely, what would be > the equivalent of > > %inner.ptr = getelementptr i8** %x, i32 1 > > assuming we're doing target independent optimizations and do not know > the size of a pointer? > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150207/0e58df55/attachment.html>
Actually, store doesn't need a type, as that's supplied by the value being stored. But load needs to know the type of the loaded value, and gep needs to know the memory layout to perform target specific offset calculations. On Sat, Feb 7, 2015 at 10:51 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote:> The difference is that %x would be just a generic pointer type, but the > type would still need to be supplied as an argument to the GEP / load / > store. > > %inner.ptr = getelementptr i8**, %x, i32 1 > > You could think of it as having an implicit bitcast on every pointer > operation. > > On Sat, Feb 7, 2015 at 10:42 AM, Sanjoy Das < > sanjoy at playingwithpointers.com> wrote: > >> How would GEP's look like in this scheme? Concretely, what would be >> the equivalent of >> >> %inner.ptr = getelementptr i8** %x, i32 1 >> >> assuming we're doing target independent optimizations and do not know >> the size of a pointer? >> >> -- Sanjoy >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150207/4c1979f1/attachment.html>
> The difference is that %x would be just a generic pointer type, but the type > would still need to be supplied as an argument to the GEP / load / store. > > %inner.ptr = getelementptr i8**, %x, i32 1 > > You could think of it as having an implicit bitcast on every pointer > operation.That makes a lot of sense, thanks! -- Sanjoy
> Actually, store doesn't need a type, as that's supplied by the value being > stored. But load needs to know the type of the loaded value, and gep needsYup, agreed. Even now one of types in "store i32 %value, i32* %ptr" is redundant -- given either the value or the pointer type the type system fixes the other. -- Sanjoy> to know the memory layout to perform target specific offset calculations. > > On Sat, Feb 7, 2015 at 10:51 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> > wrote: >> >> The difference is that %x would be just a generic pointer type, but the >> type would still need to be supplied as an argument to the GEP / load / >> store. >> >> %inner.ptr = getelementptr i8**, %x, i32 1 >> >> You could think of it as having an implicit bitcast on every pointer >> operation. >> >> On Sat, Feb 7, 2015 at 10:42 AM, Sanjoy Das >> <sanjoy at playingwithpointers.com> wrote: >>> >>> How would GEP's look like in this scheme? Concretely, what would be >>> the equivalent of >>> >>> %inner.ptr = getelementptr i8** %x, i32 1 >>> >>> assuming we're doing target independent optimizations and do not know >>> the size of a pointer? >>> >>> -- Sanjoy >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >