<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 31, 2016 at 1:43 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Thanks David. I ended up trying this over the weekend (see <a href="https://github.com/llvm-project/llvm-project/compare/master...pcc:pointertype" class="gmail_msg" target="_blank">https://github.com/llvm-project/llvm-project/compare/master...pcc:pointertype</a>). 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.<div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div></blockquote><div><br>Yep - seems helpful in that regard, for sure. Thanks for looking into it/working on it.<br><br>(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)<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Peter</div></div></div><div class="gmail_extra gmail_msg"></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Oct 31, 2016 at 11:24 AM, David Blaikie <span dir="ltr" class="gmail_msg"><<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">- Dave</div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_9207843630671585707h5 gmail_msg"><div dir="ltr" class="gmail_msg">On Sat, Oct 29, 2016 at 8:41 PM Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div></div></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="m_9207843630671585707h5 gmail_msg"><div dir="ltr" class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">Hi all,<div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"></div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">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:</div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"></div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">- 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.</div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">- PointerType will have no place in the SequentialType hierarchy once pointee types are removed, so this is a necessary step towards removing pointee types.</div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"></div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">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.</div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"></div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">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.</div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"></div><div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">Thanks,<br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">-- <br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><div class="m_9207843630671585707m_-8046995974433528455m_-360905677813911331gmail_signature m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg"><div dir="ltr" class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">-- <div class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">Peter</div></div></div>
</div></div></div></div>
_______________________________________________<br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">
LLVM Developers mailing list<br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">
<a href="mailto:llvm-dev@lists.llvm.org" class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="m_9207843630671585707m_-8046995974433528455gmail_msg gmail_msg">
</blockquote></div>
</blockquote></div><br class="gmail_msg"><br clear="all" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg">-- <br class="gmail_msg"><div class="m_9207843630671585707gmail_signature gmail_msg" data-smartmail="gmail_signature"><div dir="ltr" class="gmail_msg">-- <div class="gmail_msg">Peter</div></div></div>
</div></blockquote></div></div>