<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Happy to. I'll try to remember to take
a diff tomorrow and summarize. <br>
<br>
One case which I know we do which is of interest here is that we
fall back to O(N^2) aliasing queries for small loops in LICM
specifically to paper over imprecision in AliasSetTracker. I
don't have the test case at hand, but this was motivated by real
cases we saw. <br>
<br>
On 08/21/2016 12:14 PM, Daniel Berlin wrote:<br>
</div>
<blockquote
cite="mid:CAF4BwTUkP89cGPJoJ4nhyaaAGqwW1Me_GOeXZb6Pyb262DV_vQ@mail.gmail.com"
type="cite">
<div dir="ltr">Would you mind listing the ones related to
aliasing/memdep/etc?
<div><br>
</div>
<div>I'm trying to figure out what the best order to tackle
things in is.</div>
<div><br>
</div>
<div>For example, we could convert passes to memoryssa, we can
add optional caching to basicaa (IE aliascache), etc.</div>
<div><br>
</div>
<div>All of these produce increased scaling of various things,
and we should do all of them over time, but it would be nice
to know what we should increase the scaling of first, and the
more data, the better the plan :)</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Aug 21, 2016 at 11:06 AM,
Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 08/20/2016 10:14 PM, Xinliang David Li wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand your concern here, and performance cliff
is definitely<br>
something we should try to avoid. However dropping alias
info in<br>
situation like this != performance cliff. I am sure we
can come up<br>
with hand-created examples to show performance damage
with dropped<br>
alias info, in real programs, when a function reaches
such a state,<br>
the alias query results will be already so conservative
that doing<br>
memory disambiguation busily any further will likely be
just waste of<br>
compile time, so 'gracefully' lowering alias precision
or dropping<br>
aliasing info to the floor makes no difference
practically. I have<br>
not seen performance regressions due to the use of
cutoff limits<br>
elsewhere in LLVM.<br>
</blockquote>
</span>
I have. In fact, we have a number of the flags tuned higher
in our local builds than upstream precisely for this reason.
<div class="HOEnZb">
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
David<br>
<br>
<br>
On Sat, Aug 20, 2016 at 12:24 PM, Philip Reames<br>
<<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com"
target="_blank">listmail@philipreames.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
reames added a subscriber: reames.<br>
reames added a comment.<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>
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/D2343<wbr>2</a><br>
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>