<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/20/2016 12:59 PM, Daniel Berlin
wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTWkj1YEsWEB=L6v6JDX0-qqphjxChJ8BNbejH_8do8FYQ@mail.gmail.com"
type="cite">
<div dir="ltr">Even if you kept the ASTracker concept for some
reason, moving the ASTracker to MemorySSA also would make it
scale significantly better (let's ignore the updating through IR
changes part for a second, as it's orthogonal)<br>
<div><br>
</div>
<div>For MemorySSA, ASTracker stores only clobbering
MemoryAccesses as a SmallPtrSet.</div>
<div><br>
</div>
<div>For adding a load, you add
MSSA->getClobberingMemoryAccess(load) (this is only
necessary if memoryssa gave up optimizing uses, we could fix
this. Otherwise it's just the defining access of the load)</div>
<div>For adding a store, you add the store.</div>
<div><br>
</div>
<div>For merging, you merge the sets.</div>
<div>For querying for loads, you see if
MSSA->getClobberingMemoryAccess(load) is in the set (ditto
the above)</div>
<div>for querying for stores, you see if the store, or
MSSA->getClobberingMemoryAccess(store) is in the set.</div>
<div><br>
</div>
<div>This will scale at least a factor of N better.</div>
</div>
</blockquote>
You seem to have interpreted my comment as arguing against
MemorySSA. That was not my intent at all. If we have a realistic
chance of porting to MemorySSA in the near term (and from your other
response, it sounds like we do), then that's definitely the right
direction to move in. <br>
<blockquote
cite="mid:CAF4BwTWkj1YEsWEB=L6v6JDX0-qqphjxChJ8BNbejH_8do8FYQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Aug 20, 2016 at 12:38 PM, Hal
Finkel <span dir="ltr"><<a moz-do-not-send="true"
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">hfinkel
added a comment.<br>
<span class=""><br>
In <a moz-do-not-send="true"
href="https://reviews.llvm.org/D23432#521624"
rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23432#521624</a>,
@reames wrote:<br>
<br>
> I am not actively objecting to this patch, but I
really don't like the overall direction here. Having a
threshold where our ability to optimize falls off a
cliff just seems really undesirable. As Hal pointed
out, there are likely options for summarizing alias sets
to allow quicker AA queries. How much have we explored
that design space?<br>
<br>
<br>
</span>My understanding from the discussion is that all
uses of the ASTracker are going to be replaced with
MemorySSA-based algorithms; that is why I was okay with
this (for now). If we still need an AST concept, then
we'll want to do something more sophisticated.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
Repository:<br>
rL LLVM<br>
<br>
<a moz-do-not-send="true"
href="https://reviews.llvm.org/D23432"
rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23432</a><br>
<br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>