llvm dev - Oct 2016 - RFC: PointerType should derive from Type rather than SequentialType

Thanks David. I ended up trying this over the weekend (see
https://github.com/llvm-project/llvm-project/compare/
master...pcc:pointertype). It ended up being a net reduction in code size
so seems like a useful cleanup even independent of the typeless pointer
work, I'll see if I can send a patch to the list.

FWIW I think this directly helps towards the migration because we would
have a clearer idea of where we are legitimately calling getElementType()
on arrays or vectors as opposed to the pointer uses which we want to remove.

Peter

On Mon, Oct 31, 2016 at 11:24 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> Seems pretty plausible to me - my only question would be whether it's
> worth the churn to do this intermediate step before finishing off typeless
> pointers (granted, I've stalled out on that for nearly a year,
admittedly -
> but good to have extra hands/incentives - there's still a fair bit of
work
> to do though, so understandable if it might not be useful to block progress
> on other things to finish it off) - not sure how much work this would
> produce as an intermediate step compared to progress towards the end goal
> directly. Perhaps not much.
>
> - Dave
>
> On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> An oddity that has existed for a long time in the IR is that
PointerType
>> derives from SequentialType. Per subject I propose to make PointerType
>> derive from Type for a couple of reasons:
>>
>> - Values of type PointerType are unlike the other SequentialTypes
(arrays
>> and vectors) in that they do not hold values of the element type. By
moving
>> PointerType we can unify certain aspects of how the other
SequentialTypes
>> are handled.
>> - PointerType will have no place in the SequentialType hierarchy once
>> pointee types are removed, so this is a necessary step towards removing
>> pointee types.
>>
>> Although this would slightly complicate GEP enumeration, this can be
>> handled at the API level and is also inevitable given the move to
remove
>> pointee types.
>>
>> Specifically I want to change the API exposed by the GEP type iterator
so
>> that each iterator can be in one of three states: unbounded array (i.e.
the
>> existing PointerType state, which would represent the first
"element" of
>> the GEP), bounded array (the existing ArrayType state) or struct (the
>> existing StructType state). In the former two cases clients would not
have
>> access to the "underlying" type and would only be able to
access the
>> "boundedness", the upper bound if any and the element type.
>>
>> Thanks,
>> --
>> --
>> Peter
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161031/90e4a336/attachment.html>

On Mon, Oct 31, 2016 at 1:43 PM Peter Collingbourne <peter at pcc.me.uk>
wrote:
> Thanks David. I ended up trying this over the weekend (see
>
https://github.com/llvm-project/llvm-project/compare/master...pcc:pointertype).
> It ended up being a net reduction in code size so seems like a useful
> cleanup even independent of the typeless pointer work, I'll see if I
can
> send a patch to the list.
>
> FWIW I think this directly helps towards the migration because we would
> have a clearer idea of where we are legitimately calling getElementType()
> on arrays or vectors as opposed to the pointer uses which we want to
remove.
>
Yep - seems helpful in that regard, for sure. Thanks for looking into
it/working on it.

(I don't feel sufficiently position to sign off on this - but at least from
my perspective and that of the typeless pointer work, this seems good -
I'll leave it to others to chime in for the broader buy-in here)

- Dave

>
> Peter
>
> On Mon, Oct 31, 2016 at 11:24 AM, David Blaikie <dblaikie at
gmail.com>
> wrote:
>
> Seems pretty plausible to me - my only question would be whether it's
> worth the churn to do this intermediate step before finishing off typeless
> pointers (granted, I've stalled out on that for nearly a year,
admittedly -
> but good to have extra hands/incentives - there's still a fair bit of
work
> to do though, so understandable if it might not be useful to block progress
> on other things to finish it off) - not sure how much work this would
> produce as an intermediate step compared to progress towards the end goal
> directly. Perhaps not much.
>
> - Dave
>
> On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> An oddity that has existed for a long time in the IR is that PointerType
> derives from SequentialType. Per subject I propose to make PointerType
> derive from Type for a couple of reasons:
>
> - Values of type PointerType are unlike the other SequentialTypes (arrays
> and vectors) in that they do not hold values of the element type. By moving
> PointerType we can unify certain aspects of how the other SequentialTypes
> are handled.
> - PointerType will have no place in the SequentialType hierarchy once
> pointee types are removed, so this is a necessary step towards removing
> pointee types.
>
> Although this would slightly complicate GEP enumeration, this can be
> handled at the API level and is also inevitable given the move to remove
> pointee types.
>
> Specifically I want to change the API exposed by the GEP type iterator so
> that each iterator can be in one of three states: unbounded array (i.e. the
> existing PointerType state, which would represent the first
"element" of
> the GEP), bounded array (the existing ArrayType state) or struct (the
> existing StructType state). In the former two cases clients would not have
> access to the "underlying" type and would only be able to access
the
> "boundedness", the upper bound if any and the element type.
>
> Thanks,
> --
> --
> Peter
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> --
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161031/cc4efc3b/attachment.html>

Having heard no objections I went ahead and sent out a couple of patches to
implement this:

https://reviews.llvm.org/D26594
https://reviews.llvm.org/D26595

Peter

On Mon, Oct 31, 2016 at 1:48 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Mon, Oct 31, 2016 at 1:43 PM Peter Collingbourne <peter at
pcc.me.uk>
> wrote:
>
>> Thanks David. I ended up trying this over the weekend (see
>> https://github.com/llvm-project/llvm-project/compare/
>> master...pcc:pointertype). It ended up being a net reduction in code
>> size so seems like a useful cleanup even independent of the typeless
>> pointer work, I'll see if I can send a patch to the list.
>>
>> FWIW I think this directly helps towards the migration because we would
>> have a clearer idea of where we are legitimately calling
getElementType()
>> on arrays or vectors as opposed to the pointer uses which we want to
remove.
>>
>
> Yep - seems helpful in that regard, for sure. Thanks for looking into
> it/working on it.
>
> (I don't feel sufficiently position to sign off on this - but at least
> from my perspective and that of the typeless pointer work, this seems good
> - I'll leave it to others to chime in for the broader buy-in here)
>
> - Dave
>
>
>>
>> Peter
>>
>> On Mon, Oct 31, 2016 at 11:24 AM, David Blaikie <dblaikie at
gmail.com>
>> wrote:
>>
>> Seems pretty plausible to me - my only question would be whether
it's
>> worth the churn to do this intermediate step before finishing off
typeless
>> pointers (granted, I've stalled out on that for nearly a year,
admittedly -
>> but good to have extra hands/incentives - there's still a fair bit
of work
>> to do though, so understandable if it might not be useful to block
progress
>> on other things to finish it off) - not sure how much work this would
>> produce as an intermediate step compared to progress towards the end
goal
>> directly. Perhaps not much.
>>
>> - Dave
>>
>> On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> An oddity that has existed for a long time in the IR is that
PointerType
>> derives from SequentialType. Per subject I propose to make PointerType
>> derive from Type for a couple of reasons:
>>
>> - Values of type PointerType are unlike the other SequentialTypes
(arrays
>> and vectors) in that they do not hold values of the element type. By
moving
>> PointerType we can unify certain aspects of how the other
SequentialTypes
>> are handled.
>> - PointerType will have no place in the SequentialType hierarchy once
>> pointee types are removed, so this is a necessary step towards removing
>> pointee types.
>>
>> Although this would slightly complicate GEP enumeration, this can be
>> handled at the API level and is also inevitable given the move to
remove
>> pointee types.
>>
>> Specifically I want to change the API exposed by the GEP type iterator
so
>> that each iterator can be in one of three states: unbounded array (i.e.
the
>> existing PointerType state, which would represent the first
"element" of
>> the GEP), bounded array (the existing ArrayType state) or struct (the
>> existing StructType state). In the former two cases clients would not
have
>> access to the "underlying" type and would only be able to
access the
>> "boundedness", the upper bound if any and the element type.
>>
>> Thanks,
>> --
>> --
>> Peter
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>>
>> --
>> --
>> Peter
>>
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161113/c760b2b7/attachment.html>