<div dir="ltr">(I have no beef with using Value, FWIW)<div>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>I'm more surfacing the objections i've heard from others, than ones i have myself.</div><div>I'll forward this thread to them and let them speak for themselves if they want</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 14, 2017 at 4:57 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<p><br>
</p>
<div class="m_-3724127833870382032moz-cite-prefix">On 10/14/2017 05:28 PM, Daniel Berlin
via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<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>2017-10-14 5:03 GMT+02:00 Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">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>
</div>
</div>
</blockquote>
<br></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"><br>
<br>
-Hal</font></span><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_-3724127833870382032mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
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>mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</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></div>