<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 14, 2017 at 2:54 PM, Michael Kruse <span dir="ltr"><<a href="mailto:llvmdev@meinersbur.de" target="_blank">llvmdev@meinersbur.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-10-14 5:03 GMT+02:00 Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>>:<br>
> FWIW: We hit a subset of this issue with MemorySSA (which subclasses value<br>
> for the MemoryAccess's, etc), and it was discussed as well during<br>
> PredicateInfo.<br>
><br>
> NewGVN has a variant the same issue as well, where it actually creates<br>
> unattached (IE not in a basic block) new instructions just so it can analyze<br>
> them.<br>
><br>
> IMHO, some nice way to make virtual forms over the instructions that didn't<br>
> require reimplementing the tons of existing functionality that works with<br>
> Value would be much appreciated.<br>
><br>
> But maybe the right answer at some point is to just sit down and build out<br>
> such an infrastructure. It certainly sounds like there are enough clients.<br>
<br>
</span>What would be different in such an infrastructure? IMHO the<br>
llvm::Value hierarchy is already relatively thin, </blockquote><div><br></div><div>I think most people would disagree with "Relatively thin".</div><div>Given there have also been multiple threads in the past year with most people not wanting non-actual-IR to derive from Value, i think you may be in the minority here.<br></div><div><br></div></div></div></div>