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

[Sanjoy Das via llvm-dev]

+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.
>
>
>