[PATCH] D76483: [DivRemPairs] Freeze operands if they can be undef values

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 30 18:35:49 PDT 2020


aqjune added a comment.

In D76483#1950450 <https://reviews.llvm.org/D76483#1950450>, @sanwou01 wrote:

> Hi, I can confirm that D76010 <https://reviews.llvm.org/D76010> unfortunately doesn't fix the regression.
>
> I've narrowed the problem down to Loop Strength Reduction. It looks like SCEV can't see "through" the freeze node.
>
> I'll try to get a reduced reproducer that shows the problem; and I'll be happy to test a patch.
>
> Thanks!


I see. This link might be helpful: https://reviews.llvm.org/D70623
A possible wokaround would be to remove nsw/nuw tags from induction variable and freeze the initial value.

  loop:
    %i = phi %init, %i.inc.fr
    %i.inc = add nsw 1, %i
    %i.inc.fr = freeze %i.inc // we can optimize this out by removing nsw flag from %i.inc and freezing %init
    br (%i.inc.fr < %n), loop, exit
  =>
    %init.fr = freeze %init
  loop:
    %i = phi %init.fr, %i.inc
    %i.inc = add 1, %i
    br (%i.inc < %n), loop, exit

BTW, IIUC one of the main motivation of DivRemPairs was to help better codegen. If there is any (aggressive) optimization after DivRemPairs, wouldn't it possibly shuffle the arranged instructions?
I wonder whether making DivRemPairs fire after other optimizations in LTO makes sense.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76483/new/

https://reviews.llvm.org/D76483





More information about the llvm-commits mailing list