<div class="gmail_quote">On 19 April 2012 14:08, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</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 class="im"><div>On Apr 19, 2012, at 11:40 AM, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>> wrote:</div><br></div><blockquote type="cite">

<div class="gmail_quote"><div class="im">On 19 April 2012 09:46, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im">

Author: stoklund<br>
Date: Thu Apr 19 11:46:26 2012<br>
New Revision: 155136<br>
<br></div><div class="im">These transformations are deferred:<br>
<br>
  (X >>? C) << C   --> X & (-1 << C)  (When X >> C has multiple uses)<br>
  (X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2)   (When C2 > C1)<br>
  (X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2)  (When C1 > C2)<br></div></blockquote><div class="im"><div><br></div><div>If the form on the left is better, please make sure that we turn the code on the right into the code on the left.</div>

</div></div></blockquote><div><br></div><div>I don't think we should do that.</div><div><br></div><div>InstCombine doesn't actually have a way of knowing which expression is better, so it will just leave them alone so it at least doesn't break anything.</div>

</div></div></blockquote><div><br></div><div>The major goal of instcombine is to pick one of two equivalent code constructs, so that the backend and other IR-level optimizers can detect one pattern instead of both. Please make sure that we pick one.</div>

<div><br></div><div>SCEV is unusual in that it prefers arithmetic operations to bitwise operations; usually bitwise operations are easier to reason about because they don't carry. There is already logic in SCEV to detect an "or" which is actually an "add", and I think the right fix is to extend that. The premise is that it's easier to find an "or" which is an "add" than it is to find an "add" that is an "or". I'd be interested in hearing if you disagree with that?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>DAGCombine is better equipped to decide that.</div></div></blockquote>

<div><br></div><div>Right, the reality of the situation is that the IR-level optimizers don't know what's best for the given architecture, etc., and we end up with two fighting optimizers. Usually I decide which of the two patterns should be canonical by checking whether the existing X86 backend handles one of them better. I don't have a good answer overall.</div>

<div><br></div><div>Nick</div><div><br></div></div>