<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Disclaimer: I haven’t been following this discussion closely, nor do I know what is going on in the modern AA/MemorySSA/GVN infra, but:<div class=""><br class=""></div><div class="">I’d prefer to avoid abusing the Value* class hierarchy if reasonable. Adding new subclasses that only occur in special cases makes it more difficult to reason about what can occur and when. A historical example that always grated against my sensibilities was CodeGen/PseudoSourceValue, which originally inherited from Value in order to make it “fit better” into the AA infra. Thankfully Nick Lewycky broke that tie back in a patch on Tue Apr 15 07:22:52 2014, and the codebase has been better off for that change.</div><div class=""><br class=""></div><div class="">All this is to say that I’d prefer to avoid tying it into Value just because that is an expedient way to get something done. If tying into Value is the “right” thing to do for some reason then that is a completely different story.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 16, 2017, at 5:33 PM, Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">(I have no beef with using Value, FWIW)<div class="">I believe one of the objections is, for example, lib/IR should not have to depend on, say, lib/Analysis, which it does if you extend value ;)<br class="">I'm more surfacing the objections i've heard from others, than ones i have myself.</div><div class="">I'll forward this thread to them and let them speak for themselves if they want</div><div class=""> </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Oct 14, 2017 at 4:57 PM, Hal Finkel <span dir="ltr" class=""><<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class=""><div class=""><div class="h5"><p class=""><br class="">
</p>
<div class="m_-3724127833870382032moz-cite-prefix">On 10/14/2017 05:28 PM, Daniel Berlin
via llvm-dev wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class=""><br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Sat, Oct 14, 2017 at 2:54 PM,
Michael Kruse <span dir="ltr" class=""><<a href="mailto:llvmdev@meinersbur.de" target="_blank" class="">llvmdev@meinersbur.de</a>></span>
wrote:<br class="">
<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" target="_blank" class="">dberlin@dberlin.org</a>>:<br class="">
> FWIW: We hit a subset of this issue with MemorySSA
(which subclasses value<br class="">
> for the MemoryAccess's, etc), and it was discussed
as well during<br class="">
> PredicateInfo.<br class="">
><br class="">
> NewGVN has a variant the same issue as well, where
it actually creates<br class="">
> unattached (IE not in a basic block) new
instructions just so it can analyze<br class="">
> them.<br class="">
><br class="">
> IMHO, some nice way to make virtual forms over the
instructions that didn't<br class="">
> require reimplementing the tons of existing
functionality that works with<br class="">
> Value would be much appreciated.<br class="">
><br class="">
> But maybe the right answer at some point is to just
sit down and build out<br class="">
> such an infrastructure. It certainly sounds like
there are enough clients.<br class="">
<br class="">
</span>What would be different in such an infrastructure?
IMHO the<br class="">
llvm::Value hierarchy is already relatively thin, </blockquote>
<div class=""><br class="">
</div>
<div class="">I think most people would disagree with "Relatively
thin".</div>
<div class="">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 class="">
</div>
</div>
</div>
</div>
</blockquote>
<br class=""></div></div>
I think the way that we generally look at this is: Our IR data types
(Value, User, Instruction, Constant, and so on) are the most
efficient representation we have of the IR. There are a lot of
capabilities that come along with that hierarchy (use lists, value
handles, metadata, names). Value has a non-inline destructor to deal
with all of these capabilities, as does Instruction. Each individual
instance of these types allocate memory. The question is then: For
any particular use case, do you need those capabilities/properties?
If not, is there a more succinct representation that can be used
efficiently?<span class="HOEnZb"><font color="#888888" class=""><br class="">
<br class="">
-Hal</font></span><span class=""><br class="">
<br class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class=""><br class="">
</div>
</div>
</div>
</div>
<br class="">
<fieldset class="m_-3724127833870382032mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="">______________________________<wbr class="">_________________
LLVM Developers mailing list
<a class="m_-3724127833870382032moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-3724127833870382032moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br class="">
</span><span class=""><pre class="m_-3724127833870382032moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</span></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>