[llvm-dev] RFC: PointerType should derive from Type rather than SequentialType (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 31 11:24:31 PDT 2016

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.

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>

More information about the llvm-dev mailing list