[LLVMdev] Moving towards a singular pointer type

[Herbie Robinson]

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>