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>
This idea seems to have good merits to me. It seems like any functionality related to pointer types could determined at load/store time without the overhead of specifying pointer types in IR only to cast it away right before usage. I often found myself doing the i8* trick any time what I was pointing to didn’t easy fit in to the type system since, as others pointed out, the frontend should know what the actual types are anyway. One migration issue I could see is any time a frontend depends on the LLVM type system for tracking types rather than doing it itself. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of David Blaikie Sent: Tuesday, February 17, 2015 11:34 AM To: Chris Lattner Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Moving towards a singular pointer type On Mon, Feb 16, 2015 at 3:53 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com> > wrote: On 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 <http://llvm.org/viewvc/llvm-project?rev=226781&view=rev> &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/ecf77a7d/attachment.html>
On Feb 17, 2015, at 9:33 AM, David Blaikie <dblaikie at gmail.com> wrote:>> 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)You could say with more certainty, but I see this as an incremental way to move towards the singular pointer type model. I suspect that there will be *some* impact on the optimizer, but that the optimizer can be taught how to handle it. If you go through the effort to build a huge patch that switches the universe over to a singular pointer type, you won’t be able to land it until the optimizer regressions are fixed. This could be a very long time maintaining a large patch out of tree (never fun). In the worst case, doing this could also expose an unforeseen problem with doing this. I don’t expect that personally, but it is possible. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/047016f6/attachment.html>
On Tue, Feb 17, 2015 at 1:22 PM, Chris Lattner <clattner at apple.com> wrote:> On Feb 17, 2015, at 9:33 AM, David Blaikie <dblaikie at gmail.com> wrote: > > 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) > > > You could say with more certainty, but I see this as an incremental way to > move towards the singular pointer type model. I suspect that there will be > *some* impact on the optimizer, but that the optimizer can be taught how to > handle it. > > If you go through the effort to build a huge patch that switches the > universe over to a singular pointer type, you won’t be able to land it > until the optimizer regressions are fixed. This could be a very long time > maintaining a large patch out of tree (never fun). >Yeah, possibly - chatted about this a bit with Chandler too & his experience has been that shaking these sort of things out is often out-of-tree (granted, that's with small changes to the canonicalization of pointer types in specific places - this kind of widescale change might hit quite a few tests in-tree first before reaching the long-tail of random out-of-tree tests people run/care about) so having an out-of-tree patch won't necessarily get us far, and as you say - comes at a bit of a cost to maintain it out of tree and then transform it into the final version later once we introduce a true opaque pointer type.> In the worst case, doing this could also expose an unforeseen problem with > doing this. I don’t expect that personally, but it is possible. >Yeah, that's my personal concern just due to my unfamiliarity with this sort of thing - but I'm going to take everyone else's word for it that this is the preferred way forward & just keep pushing on with it. Sooner it can be in tree the sooner we'll have good coverage/results on it, I think. (& yeah, at various points we might have a few rounds on specific patches after they reveal perf regressions, but that seems fine - having everyone on the same code should make it easier to find/share reproductions, etc) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/c5012465/attachment.html>
On Tue, Feb 17, 2015 at 1:08 PM, Colin LeMahieu <colinl at codeaurora.org> wrote:> > > One migration issue I could see is any time a frontend depends on the LLVM > type system for tracking types rather than doing it itself. > > >This. An idiom I've used extensively is pointer-to-struct-with-name-mangled-type-information. Because of this I can rely on LLVM entirely for type tracking, which feels like a good thing. It shouldn't be a big migration issue in my case, but I'd appreciate any words of wisdom from the LLVM community. v/r, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/12994889/attachment.html>