<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/14/2017 05:28 PM, Daniel Berlin
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUCxyvVjduG+uZ50CQGM4R3NPpFa7YhM8uKFeLT9RbRyw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAF4BwTUCxyvVjduG+uZ50CQGM4R3NPpFa7YhM8uKFeLT9RbRyw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>