llvm dev - Apr 2017 - [LLVMdev] Moving towards a singular pointer type

On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Did this work ever get done? There was a long thread about it back in 2015.
>
> I wish to use IRBuilder.
> Is there any documentation?
> How do I use the singular pointer type in GEP, LOAD, STORE instructions?
>
Sorry, no, the work is not complete - for now you'll need to pass the
pointer and pointee type to a few of these functions and some will do it
for you (Getting the pointee type from the pointer type, etc). I'll
hopefully be coming back around to this in 6-9 months to continue on it
(finishing off one or two IR constructs, then making sure all the
optimizations can cope with this)

- Dave

>
> Kind Regards
>
> James
>
> On 6 February 2015 at 23:38, 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?
>>
>> 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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170416/535a6f15/attachment.html>

On 16 April 2017 at 22:24, David Blaikie <dblaikie at gmail.com> wrote:
>
>
> On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> Did this work ever get done? There was a long thread about it back in
>> 2015.
>>
>> I wish to use IRBuilder.
>> Is there any documentation?
>> How do I use the singular pointer type in GEP, LOAD, STORE
instructions?
>>
>
> Sorry, no, the work is not complete - for now you'll need to pass the
> pointer and pointee type to a few of these functions and some will do it
> for you (Getting the pointee type from the pointer type, etc). I'll
> hopefully be coming back around to this in 6-9 months to continue on it
> (finishing off one or two IR constructs, then making sure all the
> optimizations can cope with this)
>
> - Dave
>
Hi Dave,

I think if the optimizations changed from the concept of the pointer having
a type, to instead the memory location itself having the type. Then we
might make some good progress in improving the optimizations.
If one has the concept of the memory location itself having a type, it is
then obvious that any GEP operation is likely to result in a pointer to a
different memory location, and therefore have a different type. So, giving
a pointer a type is not particularly useful.
If the pointer having a type is useful in some way to optimizations, then
the GEP instruction should really be a combined GEP and BITCAST instruction.

The singular pointer type (i.e. type-less) goes some way towards achieving
this.

Kind Regards


James
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170417/0718a756/attachment.html>

On Mon, Apr 17, 2017 at 7:19 AM James Courtier-Dutton <
james.dutton at gmail.com> wrote:
> On 16 April 2017 at 22:24, David Blaikie <dblaikie at gmail.com>
wrote:
>
>>
>>
>> On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> Did this work ever get done? There was a long thread about it back
in
>>> 2015.
>>>
>>> I wish to use IRBuilder.
>>> Is there any documentation?
>>> How do I use the singular pointer type in GEP, LOAD, STORE
instructions?
>>>
>>
>> Sorry, no, the work is not complete - for now you'll need to pass
the
>> pointer and pointee type to a few of these functions and some will do
it
>> for you (Getting the pointee type from the pointer type, etc). I'll
>> hopefully be coming back around to this in 6-9 months to continue on it
>> (finishing off one or two IR constructs, then making sure all the
>> optimizations can cope with this)
>>
>> - Dave
>>
>
> Hi Dave,
>
> I think if the optimizations changed from the concept of the pointer
> having a type, to instead the memory location itself having the type.
>
Not sure I quite follow, but I'll say this:

Memory locations in LLVM are already, as I understand it, typeless - it's
never incorrect to bitcast a pointer to A to a pointer to B and then use it
(I mean, you get whatever bits were there).

The goal of the typeless pointer work is to align the types closer to this
reality, so that optimizations/transformations aren't mislead by
meaningless type information.

> Then we might make some good progress in improving the optimizations.
> If one has the concept of the memory location itself having a type, it is
> then obvious that any GEP operation is likely to result in a pointer to a
> different memory location, and therefore have a different type. So, giving
> a pointer a type is not particularly useful.
> If the pointer having a type is useful in some way to optimizations, then
> the GEP instruction should really be a combined GEP and BITCAST
instruction.
>
> The singular pointer type (i.e. type-less) goes some way towards achieving
> this.
>
> Kind Regards
>
>
> James
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170417/5106ece1/attachment.html>