<div class="gmail_quote">On Tue, Apr 17, 2012 at 1:36 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> I am not sure how best to fix this. If possible, InstCombine's canonicalization shouldn't hide arithmetic progressions behind bit masks. At least, it seems these transformations should be disabled unless (X >> C).hasOneUse(). They aren't exactly optimizations.<br>

><br>
> This:<br>
><br>
>  %div = lshr i32 %a, 2<br>
>  store i32 %div, i32* %p, align 4, !tbaa !0<br>
>  %add = shl nuw nsw i32 %div, 1<br>
><br>
> is better than this:<br>
><br>
>  %div = lshr i32 %a, 2<br>
>  store i32 %div, i32* %p, align 4, !tbaa !0<br>
>  %0 = lshr i32 %a, 1<br>
>  %add = and i32 %0, <a href="tel:2147483646" value="+12147483646" class="cremed">2147483646</a><br>
<br>
</div>I think we could try your hasOneUse idea. If we are going to keep<br>
%div, we may as well keep using it and save one instruction in the<br>
canonical form.</blockquote></div><br><div>I really dislike hasOneUse-based "solutions" at the IR / InstCombine layer. They result in strange artifacts during optimization: places where adding similar code turns off optimizations because we fold the similar bits together and reuse parts of the computation.</div>
<div><br></div><div>I would much rather see us devise a reasonable set of canonicalization rules at the IR level that don't block optimization. Tricks like saving instructions, using bit masks, etc., should all be reserved for the codegen layer / DAGCombine. There, hasOneUse makes perfect sense because you're trying to peephole through architectural gymnastics, not trying to get systematic scalar optimizations to fire.</div>
<div><br></div><div>Let's see if we have any evidence that reserving this transform for the DAGCombiner hurts things, how it hurts things, and what we can do about it first?</div>