[llvm-dev] RFC: PointerType should derive from Type rather than SequentialType
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 31 13:48:39 PDT 2016
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
> 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)
> On Mon, Oct 31, 2016 at 11:24 AM, David Blaikie <dblaikie at gmail.com>
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev