[LLVMdev] Moving towards a singular pointer type

[David Blaikie]

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>