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

Tue Jul 9 17:58:00 PDT 2019

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>