[LLVMdev] Moving towards a singular pointer type

[Chris Lattner]

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>