llvm dev - Jul 2019 - [LLVM] Infinite loop during LLVM InstructionCombining pass optimization

If you're able to reproduce the infinite loop with -O3 then you should
be able to dump out the IR that causes `opt -instcombine` to infloop,
unless the bug is truly esoteric (e.g. only caused by a specific
use-list ordering).  Maybe take a closer look at the output from `opt
-print-before-all -O3`?

Alternatively you can use bugpoint to minimize the IR to get a small
reproducer that causes `opt -O3` to hang:
http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html

-- Sanjoy

On Mon, Jul 8, 2019 at 6:02 PM Yuseok Jeon <jeon41 at purdue.edu>
wrote:
>
> Thank you for your reply.
>
>
> Could you please let me know how to dump out the IR input to InstCombine?
>
>
> Alternatively, I created bc file and IR input (It did not work with
"opt -instcombine < bug.ll") files.
>
> - I tried to create IR input to InstCombine pass using "-mllvm-
print-before-all" option.
>
> - I also created bc file using “-emit-llvm -O1 -Xclang -disable-llvm-passes
-c -o bug.bc”. You can reproduce the infinite loop using "opt -O3
bug.bc"
>
> - I attached these files into this email.
>
>
> Best Regards,
>
> Y. Jeon.
>
>
> ________________________________
> From: Sanjoy Das <sanjoy at playingwithpointers.com>
> Sent: Monday, July 8, 2019 12:52:50 AM
> To: Yuseok Jeon; llvm-dev; David Majnemer
> Subject: Re: [LLVM] Infinite loop during LLVM InstructionCombining pass
optimization
>
> +llvm-dev [usually it is best to CC the llvm dev list for these kinds
> of questions]
>
> Also +David Majnemer for InstCombine.
>
> This looks like an LLVM bug to me if it reproduces on top of tree.
> Can you dump out the IR input to InstCombine so that we can reproduce
> the infinite loop with `opt -instcombine < bug.ll`?  If yes, that
> would be a pretty reasonable bug report.
>
> -- Sanjoy
>
> On Sun, Jul 7, 2019 at 7:13 PM Yuseok Jeon <jeon41 at purdue.edu>
wrote:
> >
> > Dear Sanjoy Das,
> >
> >
> > My name is Yuseok Jeon.
> >
> > - I'm a Ph.D. student at Purdue University.
> >
> >
> > These days, I'm working on LLVM based project and in trouble
because of Infinite loop during LLVM InstructionCombining pass optimization.
> >
> >
> > Thus, I tried to look for experts who commits this LLVM pass to ask
this issue and found you.
> >
> > - I'm really sorry if this bothers you.
> >
> >
> > If you don't mind, could you please review whether this is LLVM
pass bug or my problem?
> >
> >
> > =========================================================> >
> >
> > I found an infinite loop during InstructionCombining optimization in
such an environment.
> >
> > LLVM version: 8.0 release
> > Test program: Deal.II (In SPEC CPU2006 benchmark)
> > I modified clang to forcibly mark a non-polymorphic class as a
polymorphic class to test some functions and compiled Deal.II.
> >
> > This is a detail infinite loop case (IR code).
> >
> > I only modified clang (not InstructionCombining pass).
> >
> > Step 1: (Applied fmul's Y * (-X) => -(X*Y) policy. 1
instruction -> 2 instructions)
> >
> > [Before] %153 = fmul double %129, fsub (double -0.000000e+00, double
bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*]
}* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to double)), !dbg
!3967
> >
> > [After]
> >
> > %153 = fmul double bitcast (i64 ptrtoint (i8** getelementptr inbounds
({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2)
to i64) to double), %129
> >
> > <badref> = fsub double -0.000000e+00, %153, !dbg
!DILocation(line: 483, column: 29, scope: <0x6d73b40>, inlinedAt:
!DILocation(line: 1032, column: 7, scope: <0x69a9230>)
> >
> > Step 2 (Applied fmul's SimplifyAssociativeOrCommutative policy.
More specifically, "order operands such that they are listed from right
(least complex) to left (most complex)" policy).
> >
> > [Before] %153 = fmul double bitcast (i64 ptrtoint (i8** getelementptr
inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0,
i64 2) to i64) to double), %129, !dbg !3967
> >
> > [After]  %153 = fmul double %129, bitcast (i64 ptrtoint (i8**
getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0,
inrange i32 0, i64 2) to i64) to double), !dbg !3967
> >
> > Step 3 (Applied fsub's "Fold negation into constant
operand" policy. (i.e., -(X * C) --> X * (-C)) )
> >
> > [Before] %154 = fsub double -0.000000e+00, %153, !dbg !3967
> >
> > [After] <badref> = fmul double %129, fsub (double -0.000000e+00,
double bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x
i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to double))
> >
> > After Step 3, infinte loop is started (i.e., Step1 -> step2 ->
step3 -> step1 ->step2 -> step3 -> ...).
> >
> >
===================================================================> >
> >
> > I will look forward to your response.
> >
> >
> > Thank you very much :).
> >
> >
> > Best regards,
> >
> > Y. Jeon.
> >
> >
> >

Thank you for your guide.


I dumped last IR (input IR to InstCombine pass) into "bug.ll" file by
using `opt -print-before-all -O3`.


I also created bc file using `-emit-llvm -O1 -Xclang -disable-llvm-passes -c`.

- you can reproduce the infinite loop by using `opt -O2 -instcombine <
bug.bc`.


I attached these files into this email and please let me know if you need more
files and information.


Best Regards,

Y. Jeon.

________________________________
From: Sanjoy Das <sanjoy at playingwithpointers.com>
Sent: Monday, July 8, 2019 10:12:43 PM
To: Yuseok Jeon
Cc: llvm-dev; David Majnemer
Subject: Re: [LLVM] Infinite loop during LLVM InstructionCombining pass
optimization

If you're able to reproduce the infinite loop with -O3 then you should
be able to dump out the IR that causes `opt -instcombine` to infloop,
unless the bug is truly esoteric (e.g. only caused by a specific
use-list ordering).  Maybe take a closer look at the output from `opt
-print-before-all -O3`?

Alternatively you can use bugpoint to minimize the IR to get a small
reproducer that causes `opt -O3` to hang:
http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html

-- Sanjoy

On Mon, Jul 8, 2019 at 6:02 PM Yuseok Jeon <jeon41 at purdue.edu>
wrote:
>
> Thank you for your reply.
>
>
> Could you please let me know how to dump out the IR input to InstCombine?
>
>
> Alternatively, I created bc file and IR input (It did not work with
"opt -instcombine < bug.ll") files.
>
> - I tried to create IR input to InstCombine pass using "-mllvm-
print-before-all" option.
>
> - I also created bc file using “-emit-llvm -O1 -Xclang -disable-llvm-passes
-c -o bug.bc”. You can reproduce the infinite loop using "opt -O3
bug.bc"
>
> - I attached these files into this email.
>
>
> Best Regards,
>
> Y. Jeon.
>
>
> ________________________________
> From: Sanjoy Das <sanjoy at playingwithpointers.com>
> Sent: Monday, July 8, 2019 12:52:50 AM
> To: Yuseok Jeon; llvm-dev; David Majnemer
> Subject: Re: [LLVM] Infinite loop during LLVM InstructionCombining pass
optimization
>
> +llvm-dev [usually it is best to CC the llvm dev list for these kinds
> of questions]
>
> Also +David Majnemer for InstCombine.
>
> This looks like an LLVM bug to me if it reproduces on top of tree.
> Can you dump out the IR input to InstCombine so that we can reproduce
> the infinite loop with `opt -instcombine < bug.ll`?  If yes, that
> would be a pretty reasonable bug report.
>
> -- Sanjoy
>
> On Sun, Jul 7, 2019 at 7:13 PM Yuseok Jeon <jeon41 at purdue.edu>
wrote:
> >
> > Dear Sanjoy Das,
> >
> >
> > My name is Yuseok Jeon.
> >
> > - I'm a Ph.D. student at Purdue University.
> >
> >
> > These days, I'm working on LLVM based project and in trouble
because of Infinite loop during LLVM InstructionCombining pass optimization.
> >
> >
> > Thus, I tried to look for experts who commits this LLVM pass to ask
this issue and found you.
> >
> > - I'm really sorry if this bothers you.
> >
> >
> > If you don't mind, could you please review whether this is LLVM
pass bug or my problem?
> >
> >
> > =========================================================> >
> >
> > I found an infinite loop during InstructionCombining optimization in
such an environment.
> >
> > LLVM version: 8.0 release
> > Test program: Deal.II (In SPEC CPU2006 benchmark)
> > I modified clang to forcibly mark a non-polymorphic class as a
polymorphic class to test some functions and compiled Deal.II.
> >
> > This is a detail infinite loop case (IR code).
> >
> > I only modified clang (not InstructionCombining pass).
> >
> > Step 1: (Applied fmul's Y * (-X) => -(X*Y) policy. 1
instruction -> 2 instructions)
> >
> > [Before] %153 = fmul double %129, fsub (double -0.000000e+00, double
bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*]
}* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to double)), !dbg
!3967
> >
> > [After]
> >
> > %153 = fmul double bitcast (i64 ptrtoint (i8** getelementptr inbounds
({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2)
to i64) to double), %129
> >
> > <badref> = fsub double -0.000000e+00, %153, !dbg
!DILocation(line: 483, column: 29, scope: <0x6d73b40>, inlinedAt:
!DILocation(line: 1032, column: 7, scope: <0x69a9230>)
> >
> > Step 2 (Applied fmul's SimplifyAssociativeOrCommutative policy.
More specifically, "order operands such that they are listed from right
(least complex) to left (most complex)" policy).
> >
> > [Before] %153 = fmul double bitcast (i64 ptrtoint (i8** getelementptr
inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0,
i64 2) to i64) to double), %129, !dbg !3967
> >
> > [After]  %153 = fmul double %129, bitcast (i64 ptrtoint (i8**
getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0,
inrange i32 0, i64 2) to i64) to double), !dbg !3967
> >
> > Step 3 (Applied fsub's "Fold negation into constant
operand" policy. (i.e., -(X * C) --> X * (-C)) )
> >
> > [Before] %154 = fsub double -0.000000e+00, %153, !dbg !3967
> >
> > [After] <badref> = fmul double %129, fsub (double -0.000000e+00,
double bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x
i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to double))
> >
> > After Step 3, infinte loop is started (i.e., Step1 -> step2 ->
step3 -> step1 ->step2 -> step3 -> ...).
> >
> >
===================================================================> >
> >
> > I will look forward to your response.
> >
> >
> > Thank you very much :).
> >
> >
> > Best regards,
> >
> > Y. Jeon.
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/4897c71c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.bc
Type: application/octet-stream
Size: 185892 bytes
Desc: bug.bc
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/4897c71c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.ll
Type: application/octet-stream
Size: 27446 bytes
Desc: bug.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/4897c71c/attachment-0003.obj>

I'll try to fix this is nobody else has yet. I suspect it's similar to:
https://reviews.llvm.org/rL333610
...constant expressions get grouped in with regular constants in our
pattern matching and cause trouble.

On Wed, Jul 10, 2019 at 1:45 PM Yuseok Jeon via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thank you for your guide.
>
>
> I dumped last IR (input IR to InstCombine pass) into "bug.ll"
file
> by using `opt -print-before-all -O3`.
>
>
> I also created bc file using `-emit-llvm -O1 -Xclang -disable-llvm-passes
> -c`.
>
> - you can reproduce the infinite loop by using `opt -O2 -instcombine <
> bug.bc`.
>
>
> I attached these files into this email and please let me know if you need
> more files and information.
>
>
> Best Regards,
>
> Y. Jeon.
> ------------------------------
> *From:* Sanjoy Das <sanjoy at playingwithpointers.com>
> *Sent:* Monday, July 8, 2019 10:12:43 PM
> *To:* Yuseok Jeon
> *Cc:* llvm-dev; David Majnemer
> *Subject:* Re: [LLVM] Infinite loop during LLVM InstructionCombining pass
> optimization
>
> If you're able to reproduce the infinite loop with -O3 then you should
> be able to dump out the IR that causes `opt -instcombine` to infloop,
> unless the bug is truly esoteric (e.g. only caused by a specific
> use-list ordering).  Maybe take a closer look at the output from `opt
> -print-before-all -O3`?
>
> Alternatively you can use bugpoint to minimize the IR to get a small
> reproducer that causes `opt -O3` to hang:
> http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html
>
> -- Sanjoy
>
> On Mon, Jul 8, 2019 at 6:02 PM Yuseok Jeon <jeon41 at purdue.edu>
wrote:
> >
> > Thank you for your reply.
> >
> >
> > Could you please let me know how to dump out the IR input to
InstCombine?
> >
> >
> > Alternatively, I created bc file and IR input (It did not work with
"opt
> -instcombine < bug.ll") files.
> >
> > - I tried to create IR input to InstCombine pass using "-mllvm-
> print-before-all" option.
> >
> > - I also created bc file using “-emit-llvm -O1 -Xclang
> -disable-llvm-passes -c -o bug.bc”. You can reproduce the infinite loop
> using "opt -O3 bug.bc"
> >
> > - I attached these files into this email.
> >
> >
> > Best Regards,
> >
> > Y. Jeon.
> >
> >
> > ________________________________
> > From: Sanjoy Das <sanjoy at playingwithpointers.com>
> > Sent: Monday, July 8, 2019 12:52:50 AM
> > To: Yuseok Jeon; llvm-dev; David Majnemer
> > Subject: Re: [LLVM] Infinite loop during LLVM InstructionCombining
pass
> optimization
> >
> > +llvm-dev [usually it is best to CC the llvm dev list for these kinds
> > of questions]
> >
> > Also +David Majnemer for InstCombine.
> >
> > This looks like an LLVM bug to me if it reproduces on top of tree.
> > Can you dump out the IR input to InstCombine so that we can reproduce
> > the infinite loop with `opt -instcombine < bug.ll`?  If yes, that
> > would be a pretty reasonable bug report.
> >
> > -- Sanjoy
> >
> > On Sun, Jul 7, 2019 at 7:13 PM Yuseok Jeon <jeon41 at
purdue.edu> wrote:
> > >
> > > Dear Sanjoy Das,
> > >
> > >
> > > My name is Yuseok Jeon.
> > >
> > > - I'm a Ph.D. student at Purdue University.
> > >
> > >
> > > These days, I'm working on LLVM based project and in trouble
because
> of Infinite loop during LLVM InstructionCombining pass optimization.
> > >
> > >
> > > Thus, I tried to look for experts who commits this LLVM pass to
ask
> this issue and found you.
> > >
> > > - I'm really sorry if this bothers you.
> > >
> > >
> > > If you don't mind, could you please review whether this is
LLVM pass
> bug or my problem?
> > >
> > >
> > > =========================================================>
> >
> > >
> > > I found an infinite loop during InstructionCombining optimization
in
> such an environment.
> > >
> > > LLVM version: 8.0 release
> > > Test program: Deal.II (In SPEC CPU2006 benchmark)
> > > I modified clang to forcibly mark a non-polymorphic class as a
> polymorphic class to test some functions and compiled Deal.II.
> > >
> > > This is a detail infinite loop case (IR code).
> > >
> > > I only modified clang (not InstructionCombining pass).
> > >
> > > Step 1: (Applied fmul's Y * (-X) => -(X*Y) policy. 1
instruction -> 2
> instructions)
> > >
> > > [Before] %153 = fmul double %129, fsub (double -0.000000e+00,
double
> bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, { [2 x
> i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to
> double)), !dbg !3967
> > >
> > > [After]
> > >
> > > %153 = fmul double bitcast (i64 ptrtoint (i8** getelementptr
inbounds
> ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64
> 2) to i64) to double), %129
> > >
> > > <badref> = fsub double -0.000000e+00, %153, !dbg
!DILocation(line:
> 483, column: 29, scope: <0x6d73b40>, inlinedAt: !DILocation(line:
1032,
> column: 7, scope: <0x69a9230>)
> > >
> > > Step 2 (Applied fmul's SimplifyAssociativeOrCommutative
policy. More
> specifically, "order operands such that they are listed from right
(least
> complex) to left (most complex)" policy).
> > >
> > > [Before] %153 = fmul double bitcast (i64 ptrtoint (i8**
getelementptr
> inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange
> i32 0, i64 2) to i64) to double), %129, !dbg !3967
> > >
> > > [After]  %153 = fmul double %129, bitcast (i64 ptrtoint (i8**
> getelementptr inbounds ({ [2 x i8*] }, { [2 x i8*] }* @_ZTV5PointILi3EE,
> i64 0, inrange i32 0, i64 2) to i64) to double), !dbg !3967
> > >
> > > Step 3 (Applied fsub's "Fold negation into constant
operand" policy.
> (i.e., -(X * C) --> X * (-C)) )
> > >
> > > [Before] %154 = fsub double -0.000000e+00, %153, !dbg !3967
> > >
> > > [After] <badref> = fmul double %129, fsub (double
-0.000000e+00,
> double bitcast (i64 ptrtoint (i8** getelementptr inbounds ({ [2 x i8*] }, {
> [2 x i8*] }* @_ZTV5PointILi3EE, i64 0, inrange i32 0, i64 2) to i64) to
> double))
> > >
> > > After Step 3, infinte loop is started (i.e., Step1 -> step2
-> step3
> -> step1 ->step2 -> step3 -> ...).
> > >
> > >
===================================================================> >
>
> > >
> > > I will look forward to your response.
> > >
> > >
> > > Thank you very much :).
> > >
> > >
> > > Best regards,
> > >
> > > Y. Jeon.
> > >
> > >
> > >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/e5f8f38d/attachment.html>