[LLVMdev] Moving towards a singular pointer type

[David Blaikie]

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>