[PATCH] Reassociate GEP operands for loop invariant code motion

[Jingyue Wu]

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 (
http://reviews.llvm.org/D6196).

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.

On Mon, Apr 20, 2015 at 10:09 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> >> 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 (
> https://llvm.org/bugs/show_bug.cgi?id=21148) 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?
>
> Actually, widening the induction variable looks like an orthogonal
> issue to re-associating GEPs.  As mentioned in the bug, the right fix
> to the widening issue is to not widen if wide integer ops are more
> expensive for the target -- if LSR is widening indvars when it
> shouldn't perhaps that part of LSR should be predicated on a target
> specific hook also?
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150421/722eacae/attachment.html>