It's an idea been thrown around in a few different threads (including Rafael's recent http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) so I'm putting up my hand to volunteer to do the work & interested in getting a bit more feedback, thoughts on best approaches, timing, etc. For some more detail: pointer types (i32*, %foo*, etc) complicate IR canonicalization. store + load should be the same instructions given the same number of bytes stored to memory, but instead we can have store float, store int, etc, etc. Another point Chandler made was that the bitcasts involved when a pointer isn't of the right type results in extra IR instructions we don't really need. So the general idea is that all pointers would just be called "ptr" (pointer? void*?). Is this something everyone feels is the right direction? Any reason why it wouldn't be? Beyond that, I'm trying to think about how to do this & I haven't hit on a terribly convincing way to do this incrementally. I could introduce the alternative form of "store" that provides the magic pointer type, then set about adding overloads (is that possible?) of any instruction consuming a pointer type, writing the usual LLVM regression tests as I go. Eventually, once this looks like it's functioning, I could start porting IRbuilder and Clang over to the new store operations & other sources of pointers. Then remove the old stuff. Are IR instructions overloadable like this? If not, would it be worthwhile to introduce separate names for the typeless-pointer forms (gep_ptr, store_ptr, etc) as a temporary means to have both sets of semantics then rename them all back once the old ones are removed? Other ideas/thoughts? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150206/22d560b9/attachment.html>
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
On Fri, Feb 6, 2015 at 4:12 PM, 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? > >Haven't we been moving towards always having at least some basic target information like datalayout and such (which includes pointer size)? -- Sean Silva> -- 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/20150206/cc99c8d6/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. 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>
On Fri, Feb 6, 2015 at 3:38 PM, David Blaikie <dblaikie at gmail.com> wrote:> It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) > so I'm putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't hit on a > terribly convincing way to do this incrementally. I could introduce the > alternative form of "store" that provides the magic pointer type, then set > about adding overloads (is that possible?) of any instruction consuming a > pointer type, writing the usual LLVM regression tests as I go. Eventually, > once this looks like it's functioning, I could start porting IRbuilder and > Clang over to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be worthwhile > to introduce separate names for the typeless-pointer forms (gep_ptr, > store_ptr, etc) as a temporary means to have both sets of semantics then > rename them all back once the old ones are removed? > > Other ideas/thoughts? >I'm wondering how geps will work when the pointer type doesn't encode the stride that each index must take. Maybe it would have to be (strawman syntax) gep<%T> off of a typeless base pointer? -- Sean Silva> > > - David > > _______________________________________________ > 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/20150206/f14189af/attachment.html>
I'm more concerned about the impact on the front end api. It's sometimes convenient at the moment to allow LLVM to track types, even if only in memory, or only as a hint, and not serialised to/from bitcode. Perhaps the right first step is to merge bitcasts into each instruction that takes a pointer argument, with the default type taken from the current value. And turn pointer bitcasts into something like a constant expression. On Sat, Feb 7, 2015 at 10:08 AM, David Blaikie <dblaikie at gmail.com> wrote:> It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) > so I'm putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't hit on a > terribly convincing way to do this incrementally. I could introduce the > alternative form of "store" that provides the magic pointer type, then set > about adding overloads (is that possible?) of any instruction consuming a > pointer type, writing the usual LLVM regression tests as I go. Eventually, > once this looks like it's functioning, I could start porting IRbuilder and > Clang over to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be worthwhile > to introduce separate names for the typeless-pointer forms (gep_ptr, > store_ptr, etc) as a temporary means to have both sets of semantics then > rename them all back once the old ones are removed? > > Other ideas/thoughts? > > - David > > _______________________________________________ > 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/f5dba268/attachment.html>
I think we should keep GEP essentially the same, but disassociate the type being GEPd over from the type of the operands. So, assuming the new ptr type is spelled "ptr", we could use this syntax: %inner.ptr = getelementptr ptr, ptr %x, i32 1 Or if I was adding 1 to a "struct A*" value in C: %next_elt = getelementptr %struct.A, ptr %x, i32 1 Ditto for all other instructions that care about pointee types, like load and store: %v = load i32, ptr %p ; loads already know (and store!) their loaded type internally store i32 %v, ptr %p ; no need to duplicate that %p points to, we have the type on %v I don't think this can be incremental, I think it all goes at once. I think you might need to add a new GEP bitcode opcode, since that instruction grows a new type operand that doesn't come from an operand type or result type. It also wouldn't be too hard to accept the old .ll syntax, since the upgrade path mostly discards information. On Fri, Feb 6, 2015 at 4:12 PM, 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/20150206/dd1f9b84/attachment.html>
On 2/6/15 7:26 PM, Sean Silva wrote:> > > On Fri, Feb 6, 2015 at 3:38 PM, David Blaikie <dblaikie at gmail.com > <mailto:dblaikie at gmail.com>> wrote: > > It's an idea been thrown around in a few different threads > (including Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's > http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) so I'm > putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate > IR canonicalization. store + load should be the same instructions > given the same number of bytes stored to memory, but instead we > can have store float, store int, etc, etc. Another point Chandler > made was that the bitcasts involved when a pointer isn't of the > right type results in extra IR instructions we don't really need. > > So the general idea is that all pointers would just be called > "ptr" (pointer? void*?). > > Is this something everyone feels is the right direction? Any > reason why it wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't > hit on a terribly convincing way to do this incrementally. I could > introduce the alternative form of "store" that provides the magic > pointer type, then set about adding overloads (is that possible?) > of any instruction consuming a pointer type, writing the usual > LLVM regression tests as I go. Eventually, once this looks like > it's functioning, I could start porting IRbuilder and Clang over > to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be > worthwhile to introduce separate names for the typeless-pointer > forms (gep_ptr, store_ptr, etc) as a temporary means to have both > sets of semantics then rename them all back once the old ones are > removed? > > Other ideas/thoughts? > > > I'm wondering how geps will work when the pointer type doesn't encode > the stride that each index must take. Maybe it would have to be > (strawman syntax) gep<%T> off of a typeless base pointer? > > -- Sean Silva >Or the offsets to gep could all be in bytes and you could introduce two new types of constants: FieldOffset (type, field) and ArrayStride(element type) -- The ArrayStride constant would be used with multiply (and would probably have other uses). I've seen this work well in other compilers and to be truthful GEP is a little weird for source languages that allow expression extents for aggregates. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150207/9cdaedeb/attachment.html>
On Fri, Feb 6, 2015 at 3:38 PM, David Blaikie <dblaikie at gmail.com> wrote:> It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) > so I'm putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. >FWIW: This is actually a real source of annoyance when doing value numbering/PRE/insertion based stuff. Current GVN essentially inserts them willy nilly to get the right types in the right places when playing with loads/stores. It also spends a bunch of time trying to look through them. Essentially, it's just another instruction to walk that gives you nothing, but has to be "worked around" if it ended up in the wrong place, etc. It's like GCC's NOP_EXPR. Here's what happened in the GCC world because of this: grep -i strip_nops *|wc -l 229 It's essentially littered around the codebase> So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't hit on a > terribly convincing way to do this incrementally. I could introduce the > alternative form of "store" that provides the magic pointer type, then set > about adding overloads (is that possible?) of any instruction consuming a > pointer type, writing the usual LLVM regression tests as I go. Eventually, > once this looks like it's functioning, I could start porting IRbuilder and > Clang over to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be worthwhile > to introduce separate names for the typeless-pointer forms (gep_ptr, > store_ptr, etc) as a temporary means to have both sets of semantics then > rename them all back once the old ones are removed? > > Other ideas/thoughts? > > - David > > _______________________________________________ > 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/b8ee5bd1/attachment.html>
Kuperstein, Michael M
2015-Feb-08 09:13 UTC
[LLVMdev] Moving towards a singular pointer type
One reservation about this being “singular” - we are still going to have a different pointer type per address space, right? From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Blaikie Sent: Saturday, February 07, 2015 01:38 To: LLVM Developers Mailing List Subject: [LLVMdev] Moving towards a singular pointer type It's an idea been thrown around in a few different threads (including Rafael's recent http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) so I'm putting up my hand to volunteer to do the work & interested in getting a bit more feedback, thoughts on best approaches, timing, etc. For some more detail: pointer types (i32*, %foo*, etc) complicate IR canonicalization. store + load should be the same instructions given the same number of bytes stored to memory, but instead we can have store float, store int, etc, etc. Another point Chandler made was that the bitcasts involved when a pointer isn't of the right type results in extra IR instructions we don't really need. So the general idea is that all pointers would just be called "ptr" (pointer? void*?). Is this something everyone feels is the right direction? Any reason why it wouldn't be? Beyond that, I'm trying to think about how to do this & I haven't hit on a terribly convincing way to do this incrementally. I could introduce the alternative form of "store" that provides the magic pointer type, then set about adding overloads (is that possible?) of any instruction consuming a pointer type, writing the usual LLVM regression tests as I go. Eventually, once this looks like it's functioning, I could start porting IRbuilder and Clang over to the new store operations & other sources of pointers. Then remove the old stuff. Are IR instructions overloadable like this? If not, would it be worthwhile to introduce separate names for the typeless-pointer forms (gep_ptr, store_ptr, etc) as a temporary means to have both sets of semantics then rename them all back once the old ones are removed? Other ideas/thoughts? - David --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150208/21ba1574/attachment.html>
I imagine/assume that distinct pointer types per address space are still necessary, but I haven't looked at address spaces in any particular detail. On Feb 8, 2015 1:13 AM, "Kuperstein, Michael M" < michael.m.kuperstein at intel.com> wrote:> One reservation about this being “singular” - we are still going to have > a different pointer type per address space, right? > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *David Blaikie > *Sent:* Saturday, February 07, 2015 01:38 > *To:* LLVM Developers Mailing List > *Subject:* [LLVMdev] Moving towards a singular pointer type > > > > It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) > so I'm putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't hit on a > terribly convincing way to do this incrementally. I could introduce the > alternative form of "store" that provides the magic pointer type, then set > about adding overloads (is that possible?) of any instruction consuming a > pointer type, writing the usual LLVM regression tests as I go. Eventually, > once this looks like it's functioning, I could start porting IRbuilder and > Clang over to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be worthwhile > to introduce separate names for the typeless-pointer forms (gep_ptr, > store_ptr, etc) as a temporary means to have both sets of semantics then > rename them all back once the old ones are removed? > > Other ideas/thoughts? > > - David > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150208/756b7f2b/attachment.html>
> On Feb 6, 2015, at 3:38 PM, David Blaikie <dblaikie at gmail.com> wrote: > > It's an idea been thrown around in a few different threads (including Rafael's recent http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html <http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html> and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev <http://llvm.org/viewvc/llvm-project?rev=226781&view=rev> ) so I'm putting up my hand to volunteer to do the work & interested in getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR canonicalization. store + load should be the same instructions given the same number of bytes stored to memory, but instead we can have store float, store int, etc, etc. Another point Chandler made was that the bitcasts involved when a pointer isn't of the right type results in extra IR instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it wouldn't be?Hi David, You can emulate this by having clang always generate "i8*” as the general type, then bitcast to "%Foo*” before doing a GEP. Have you prototyped this change (with this approach, or any other one) to see what it does to the optimizers? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/3fa3dad4/attachment.html>
On Mon, Feb 16, 2015 at 3:53 PM, Chris Lattner <clattner at apple.com> wrote:> > On Feb 6, 2015, at 3:38 PM, David Blaikie <dblaikie at gmail.com> wrote: > > It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) > so I'm putting up my hand to volunteer to do the work & interested in > getting a bit more feedback, thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > > Hi David, > > You can emulate this by having clang always generate "i8*” as the general > type, then bitcast to "%Foo*” before doing a GEP. Have you prototyped this > change (with this approach, or any other one) to see what it does to the > optimizers? >No, I haven't tried prototyping it. It's a fair point, though I'm not sure how much of that work would be thrown out (some of it would be reusable - since it'll force the front end to track type information wehre it might've previously been relying on the IR types). Reckon it's worthwhile? (I can certainly see that side of it - throwing all this churn in when we don't quite know how it'll play out in the end seem risky, but it seemed like those who're invested in this stuff felt pretty certain it was the right way to go) - David> > -Chris >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/f3cc3bb2/attachment.html>
James Courtier-Dutton via llvm-dev
2017-Apr-16 09:33 UTC
[llvm-dev] [LLVMdev] Moving towards a singular pointer type
Hi, Did this work ever get done? There was a long thread about it back in 2015. I wish to use IRBuilder. Is there any documentation? How do I use the singular pointer type in GEP, LOAD, STORE instructions? Kind Regards James On 6 February 2015 at 23:38, David Blaikie <dblaikie at gmail.com> wrote:> It's an idea been thrown around in a few different threads (including > Rafael's recent http://lists.cs.uiuc.edu/pipermail/llvm-commits/ > Week-of-Mon-20141201/247285.html and Chandler's http://llvm.org/ > viewvc/llvm-project?rev=226781&view=rev ) so I'm putting up my hand to > volunteer to do the work & interested in getting a bit more feedback, > thoughts on best approaches, timing, etc. > > For some more detail: pointer types (i32*, %foo*, etc) complicate IR > canonicalization. store + load should be the same instructions given the > same number of bytes stored to memory, but instead we can have store float, > store int, etc, etc. Another point Chandler made was that the bitcasts > involved when a pointer isn't of the right type results in extra IR > instructions we don't really need. > > So the general idea is that all pointers would just be called "ptr" > (pointer? void*?). > > Is this something everyone feels is the right direction? Any reason why it > wouldn't be? > > Beyond that, I'm trying to think about how to do this & I haven't hit on a > terribly convincing way to do this incrementally. I could introduce the > alternative form of "store" that provides the magic pointer type, then set > about adding overloads (is that possible?) of any instruction consuming a > pointer type, writing the usual LLVM regression tests as I go. Eventually, > once this looks like it's functioning, I could start porting IRbuilder and > Clang over to the new store operations & other sources of pointers. Then > remove the old stuff. > > Are IR instructions overloadable like this? If not, would it be worthwhile > to introduce separate names for the typeless-pointer forms (gep_ptr, > store_ptr, etc) as a temporary means to have both sets of semantics then > rename them all back once the old ones are removed? > > Other ideas/thoughts? > > - David > > _______________________________________________ > 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/20170416/cb31afbd/attachment.html>
David Blaikie via llvm-dev
2017-Apr-16 21:24 UTC
[llvm-dev] [LLVMdev] Moving towards a singular pointer type
On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > Did this work ever get done? There was a long thread about it back in 2015. > > I wish to use IRBuilder. > Is there any documentation? > How do I use the singular pointer type in GEP, LOAD, STORE instructions? >Sorry, no, the work is not complete - for now you'll need to pass the pointer and pointee type to a few of these functions and some will do it for you (Getting the pointee type from the pointer type, etc). I'll hopefully be coming back around to this in 6-9 months to continue on it (finishing off one or two IR constructs, then making sure all the optimizations can cope with this) - Dave> > Kind Regards > > James > > On 6 February 2015 at 23:38, David Blaikie <dblaikie at gmail.com> wrote: > >> It's an idea been thrown around in a few different threads (including >> Rafael's recent >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html >> and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev ) >> so I'm putting up my hand to volunteer to do the work & interested in >> getting a bit more feedback, thoughts on best approaches, timing, etc. >> >> For some more detail: pointer types (i32*, %foo*, etc) complicate IR >> canonicalization. store + load should be the same instructions given the >> same number of bytes stored to memory, but instead we can have store float, >> store int, etc, etc. Another point Chandler made was that the bitcasts >> involved when a pointer isn't of the right type results in extra IR >> instructions we don't really need. >> >> So the general idea is that all pointers would just be called "ptr" >> (pointer? void*?). >> >> Is this something everyone feels is the right direction? Any reason why >> it wouldn't be? >> >> Beyond that, I'm trying to think about how to do this & I haven't hit on >> a terribly convincing way to do this incrementally. I could introduce the >> alternative form of "store" that provides the magic pointer type, then set >> about adding overloads (is that possible?) of any instruction consuming a >> pointer type, writing the usual LLVM regression tests as I go. Eventually, >> once this looks like it's functioning, I could start porting IRbuilder and >> Clang over to the new store operations & other sources of pointers. Then >> remove the old stuff. >> >> Are IR instructions overloadable like this? If not, would it be >> worthwhile to introduce separate names for the typeless-pointer forms >> (gep_ptr, store_ptr, etc) as a temporary means to have both sets of >> semantics then rename them all back once the old ones are removed? >> >> Other ideas/thoughts? >> >> - David >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170416/535a6f15/attachment.html>