<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 2:35 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 12:16 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Let's not assume a dichotomy between storing a int64 in<br>
llvm::Instruction and bitwise tricks -- they're both ways of caching<br>
position within llvm::Instruction.  I think we first need to establish<br>
that we need such a cache in llvm::Instruction/llvm::BasicBlock at<br>
all.<br></blockquote></div></div></blockquote><div><br></div><div>After thinking more about this over the day, I thought about the bugs we have when the cache isn't on the BasicBlock or Instruction. We have one here: <a href="https://reviews.llvm.org/D50377">https://reviews.llvm.org/D50377</a><br><br></div><div>I would say that, while the expensive queries come from just a few passes (DSE & memcpyopt), OrderedBasicBlock is widely used by more than just a few transforms. Putting aside performance, the existence of all those OrderedBasicBlock caches tells me that yes, we do need to cache this info, and it is widely used. Maybe it doesn't need to live directly on Instruction, but the cache should be maintained by BasicBlock.</div></div></div></div>