<div dir="ltr">LSR doesn't widen indvars; IndVarSimplify which lives in a separate pass does that. And then yes, I disabled induction variable widening (but not LSR) for the NVPTX backend by looking at arithmetic costs (<a href="http://reviews.llvm.org/D6196">http://reviews.llvm.org/D6196</a>). <div><br></div><div>Speaking of indvar widening, all I meant was, if the wider bit-width were not an issue and we could enable indvar widening in NVPTX, LSR would be more effective on our cases because ScalarEvolution needn't worry about sext/zext any more. <br><div><br><div class="gmail_quote">On Mon, Apr 20, 2015 at 10:09 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> Indvar widening alleviates this nsw issue for lots of architectures. However, it's not a good option for GPU programs again because most GPUs support only i32 natively. If LSR fails to simplify the loop, then indvar widening can negatively affect performance (<a href="https://llvm.org/bugs/show_bug.cgi?id=21148" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=21148</a>) because 64-bit arithmetic is much more expensive than 32-bit. P.S. maybe we can narrow an induction variable back to its original size on LSR failure?<br>
<br>
Actually, widening the induction variable looks like an orthogonal<br>
issue to re-associating GEPs.  As mentioned in the bug, the right fix<br>
to the widening issue is to not widen if wide integer ops are more<br>
expensive for the target -- if LSR is widening indvars when it<br>
shouldn't perhaps that part of LSR should be predicated on a target<br>
specific hook also?<br>
<br>
-- Sanjoy<br>
</blockquote></div></div></div></div>