[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