llvm dev - Feb 2015 - [LLVMdev] Moving towards a singular pointer type

I imagine/assume that distinct pointer types per address space are still
necessary, but I haven't looked at address spaces in any particular detail.
On Feb 8, 2015 1:13 AM, "Kuperstein, Michael M" <
michael.m.kuperstein at intel.com> wrote:
>  One reservation about this being “singular” - we are still going to have
> a different pointer type per address space, right?
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *David Blaikie
> *Sent:* Saturday, February 07, 2015 01:38
> *To:* LLVM Developers Mailing List
> *Subject:* [LLVMdev] Moving towards a singular pointer type
>
>
>
> 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?
>
> - David
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150208/756b7f2b/attachment.html>

On 8 Feb 2015, at 16:53, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> I imagine/assume that distinct pointer types per address space are still
necessary, but I haven't looked at address spaces in any particular detail.
We probably have the weirdest pointer requirements (an out-of-tree target with
pointers that are not integers[1]).  I don't believe that this would cause
problems for us, as long as we can differentiate pointers in different address
spaces.

Being able to strip out all of the casts to and from i8* that various bits of
clang insert because certain intrinsics take an i8* and so pointers must be cast
and cast back would simplify things a lot for us (in particular, clang often
picks an i8* in the wrong AS - it wouldn't if there were no bitcast at all).

I wonder what the effects would be on TBAA?  Would pointers still have some
metadata associated with them to indicate what their types were, or would this
just be attached to the corresponding load / store instructions?

David

[1] Not sure when slides and videos will appear for this, but hopefully soon:
https://fosdem.org/2015/schedule/event/llvmmagicland/

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of David Chisnall
[..]
> [1] Not sure when slides and videos will appear for this, but hopefully
soon:
> https://fosdem.org/2015/schedule/event/llvmmagicland/

The slides can be found here:

http://www.llvm.org/devmtg/2015-02/

(hidden in the 'meetings' link on the left of the website
(http://www.llvm.org/devmtg/))

Greetings,

Jeroen Dobbelaere

On 02/09/2015 05:34 AM, David Chisnall wrote:
> On 8 Feb 2015, at 16:53, David Blaikie <dblaikie at gmail.com> wrote:
>> I imagine/assume that distinct pointer types per address space are
still necessary, but I haven't looked at address spaces in any particular
detail.
> We probably have the weirdest pointer requirements (an out-of-tree target
with pointers that are not integers[1]).  I don't believe that this would
cause problems for us, as long as we can differentiate pointers in different
address spaces.
>
> Being able to strip out all of the casts to and from i8* that various bits
of clang insert because certain intrinsics take an i8* and so pointers must be
cast and cast back would simplify things a lot for us (in particular, clang
often picks an i8* in the wrong AS - it wouldn't if there were no bitcast at
all).
>
> I wonder what the effects would be on TBAA?  Would pointers still have some
metadata associated with them to indicate what their types were, or would this
just be attached to the corresponding load / store instructions?
>
> David
As with David, I know of no issues moving to a singular pointer type per 
address space.  Having the type on the load or store instruction is 
perfectly adequate for GC barrier and safepoint insertion purposes.

Philip