<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 11:29 AM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Feb 27, 2017, at 10:11 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:</div><br class="m_-8094851141848933186Apple-interchange-newline"><div>
<div bgcolor="#FFFFFF" text="#000000"><p><br>
</p>
<div class="m_-8094851141848933186moz-cite-prefix">On 02/27/2017 11:47 AM, Adam Nemet
wrote:<br>
</div>
<blockquote type="cite">
<br>
<div>
<blockquote type="cite">
<div>On Feb 27, 2017, at 9:39 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div>
<br class="m_-8094851141848933186Apple-interchange-newline">
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 27, 2017 at 9:29
AM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div><span class="m_-8094851141848933186gmail-">
<blockquote type="cite">
<div>On Feb 27, 2017, at 7:27 AM,
Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>
wrote:</div>
<br class="m_-8094851141848933186gmail-m_8239107560126363242Apple-interchange-newline">
<div>
<div class="m_-8094851141848933186gmail-m_8239107560126363242moz-cite-prefix" style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)"><br class="m_-8094851141848933186gmail-m_8239107560126363242Apple-interchange-newline">
On 02/27/2017 06:29 AM, Nema, Ashutosh
wrote:<br>
</div>
<blockquote type="cite" style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
<div class="m_-8094851141848933186gmail-m_8239107560126363242WordSection1">
<div>Thanks
for looking into this.</div>
<div> </div>
<div>1)
Issues with re running vectorizer:</div>
<div>Vectorizer
might generate redundant alias
checks while vectorizing epilog
loop.</div>
<div>Redundant
alias checks are expensive, we like
to reuse the results of already
computed alias checks.</div>
<div>With
metadata we can limit the width of
epilog loop, but not sure about
reusing alias check result.</div>
<div>Any
thoughts on rerunning vectorizer
with reusing the alias check result
?</div>
</div>
</blockquote>
<br style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
<span style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">One way of looking at this is:
Reusing the alias-check result is really
just a conditional propagation problem;
if we don't already have an optimization
that can combine these after the fact,
then we should.</span><br style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
</div>
</blockquote>
<div><br>
</div>
</span>
<div>+Danny</div>
<div><br>
</div>
<div>Isn’t Extended SSA supposed to
help with this?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, it will solve this with no issue
already. GVN probably does already too.</div>
<div><br>
</div>
<div>even if if you have</div>
<div><br>
</div>
<div>if (a == b)</div>
<div>
<div>if (a == c)</div>
</div>
<div>
<div> if (a == d)</div>
</div>
<div>
<div> if (a == e)</div>
</div>
<div>
<div> if (a == g)</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>and we can prove a ... g equivalent,
newgvn will eliminate them all and set all the
branches true.</div>
<div><br>
</div>
<div>If you need a simpler clean up pass, we
could run it on sub-graphs.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes we probably don’t want to run a full GVN after the
“loop-scheduling” passes.</div>
</div>
</blockquote>
<br>
FWIW, we could, just without the memory-dependence analysis enabled
(i.e. set the NoLoads constructor parameter to true). GVN is pretty
fast in that mode.<br></div></div></blockquote><div><br></div></div></div><div>OK. Another data point is that I’ve seen cases in the past where the alias checks required for the loop passes could enable GVN to remove redundant loads/stores. Currently we can only pick these up with LTO when GVN is rerun.</div></div></div></blockquote><div><br></div><div>This is just GVN brokenness, newgvn should not have this problem.</div><div>If it does, i'd love to see it.</div><div><br></div><div>(I'm working on the last few parts of turning it on by default, but it requires a new getModRefInfo interface to be able to get the last few testcases)</div><div><br></div></div></div></div>