[llvm-dev] RFC: PointerType should derive from Type rather than SequentialType

[David Blaikie via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161031/ceee6acc/attachment.html>