Sanjoy Das via llvm-dev
2019-Jul-09 02:12 UTC
[llvm-dev] [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. > > > > > >
Yuseok Jeon via llvm-dev
2019-Jul-10 00:58 UTC
[llvm-dev] [LLVM] Infinite loop during LLVM InstructionCombining pass optimization
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>
Sanjay Patel via llvm-dev
2019-Jul-10 22:13 UTC
[llvm-dev] [LLVM] Infinite loop during LLVM InstructionCombining pass optimization
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>