<div class="gmail_quote">On Tue, Apr 17, 2012 at 12:23 AM, 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">
I am not sure how best to fix this. If possible, InstCombine's canonicalization shouldn't hide arithmetic progressions behind bit masks.</blockquote></div><br><div>The entire concept of cleverly converting arithmetic to bit masks seems like the perfect domain for DAGCombine instead of InstCombine:</div>
<div><br></div><div>1) We know the architecture, so we can make intelligent decisions about what masks are cheap or expensive.</div><div>2) We know the addressing modes so we can fold arithmetic into them</div><div>3) There are no more high-level optimizations we're trying to enable: gvn, scev, loop opts, other deep math optimizations have all already had their shot at the code.</div>
<div><br></div><div>Does sinking these into the DAGCombine layer help? How much does it break?</div><div><br></div><div>In the past, LLVM has been incredibly sensitive to canonicalization changes, so I'm worried, but I've also seen a *ton* of code similar to what you posted, and it simply makes no sense to me.</div>
<div><br></div><div>I wrote a pile of heroics in the addressing mode matching for x86 to specifically work around these obnoxious representations.</div>