<div dir="ltr">Hi Sanjoy,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 11, 2017 at 7:37 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@google.com" target="_blank">sanjoy@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexandre,<br>
<br>
Right now there is no phase where we simplify or canonicalize SCEV<br>
expressions after their creation -- the shape of a SCEV expression is<br>
expected to be canonical when you create it.  For this reason the<br>
right place to do the simplification you suggest is during the<br>
creation of the SCEV expression itself (createSCEV).<br></blockquote><div><br></div><div>I guess I will have to add a new case in getAddExpr. (which is already huge!)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If there is a general strategy here that isn't too complex, I'd<br>
suggest going with that; otherwise detecting some simple patterns that<br>
you care about is fine too.<br></blockquote><div><br></div><div>The idea is to simplify:</div><div><br></div><div>    zext(trunc(%a))+shl(lshr(%a))</div><div><br></div><div>Into `%a`.</div><div><br></div><div>The problem is that sometime trunc has been sunk into %a, and shl/lshr are encoded as UDiv/Mul.</div><div>This is a little bit difficult to match the general case. Also, this can be generalized in splitting %a into three, or more parts.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as your initial question is concerned (which I am sorry for not<br>
replying too -- it looks like it slipped through the cracks somehow):<br>
if there isn't a universal good reason to pick one over the other, I<br>
think we should just pick one as the normal form as per our<br>
convenience and teach downstream users to how to effectively use it.<br></blockquote><div><br></div><div>Here there is a good reason to pick the zext-trunc version as the range/known-bits analysis are exact.</div><div>While the subtraction make those over-estimated.</div><div>I am wondering if I should not generate a zext-trunc-sub-mul-div when it is not a power-of-two to bound the result of the subtraction...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For instance, if we choose the zext-trunc version as the canonical<br>
form then we should teach the 2D array GEP generation logic (not sure<br>
if there is such a thing in LLVM today?) that is equivalent to the<br>
udiv-mul form, perhaps by helpers on ScalarEvolution itself.<br></blockquote><div><br></div><div>If I fold the add expression the GEP should end up all right by itself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks!<br>
-- Sanjoy</blockquote><div><br></div><div>Best regard. </div></div><div><br></div>-- <br><div class="m_2035935729063320770gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div></div>