Performance degradations of several tests from eembc.2.0 suite on x86 Avoton-1.7 due to ‘[SimplifyCFG] Be more aggressive’

[llvmbot]

Bugzilla Link	22616
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@adibiagio,@Delena,@hfinkel,@jmolloy,@rotateright

Extended Description

While our performance testing regressions on tests rgbcmykv2 (more than 20%), mp4decod, mp2enf32, mp2enfix from eembc.2.0 suite and Coremark test were detected. Bisect analysis showed LLVM revision 229099 is responsible for these degradations. This revision enabled ‘[SimplifyCFG] Be more aggressive’ as described in comments.

commit c76bff0
Author: James Molloy james.molloy@arm.com
Date: Fri Feb 13 10:48:30 2015 +0000

[SimplifyCFG] Be more aggressive

Up the phi node folding threshold from a cheap "1" to a meagre "2".

Update tests for extra added selects and slight code churn.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229099 91177308-0d34-0410-b5e6-96231b3b80d8

[hfinkel]

On exactly which x86 architectures were these run?

[llvmbot]

Silvermont (Avoton is the micro-server variant).

[llvmbot]

Silvermont (Avoton is the micro-server variant).

o2 optset has the following options:
-O2 -ffast-math -m32 -mfpmath=sse -march=slm

And Coremark degraded on Haswell architecture with 3 optsets.
E.g., o2_32 optset:
-O2 -ffast-math -static -m32 -mfpmath=sse -march=core-avx2

[jmolloy]

Hi,

The change was a slight bump to a heuristic. I was slightly worried because this does have the potential for sideeffects, for example a select being produced where we previously created a branch.

We do aggressively remove selects and create branches from them in CodeGenPrepare, so I doubted this would cause a problem. Selects are better for analysis throughout the midend, so I thought this change was going in the right direction.

Could you please find out what codegen difference is happening? If we can trace this back to the midend hoisting something it shouldn't, we can fix that. But it could just be pure dumb luck (branch->select and codegenprepare not removing it/ branch alignment / loop head alignment) - eembc and coremark are both tiny - eembc in particular has inner loops with about 5 instructions in.

I ran EEMBC, coremark, dhrystone and the other usual suspects on AArch64 without degradation, so could you please narrow down the codegen difference?

Cheers,

James

[llvmbot]

Hi,
.....
I ran EEMBC, coremark, dhrystone and the other usual suspects on AArch64
without degradation, so could you please narrow down the codegen difference?

Hi,
I am investiging perf. difference in asm codes and then in IR.
Comments will follow.

Regards,
Sergey

[llvmbot]

eembc_2_0/rgbcmykv2:

More aggressive applying of “Simplify cfg” and deleting of outer level of if-statement leads on this test to 2 performance drawbacks. The first one is adding of 2 “unconditional” chains of operations ‘movzbl,mov,cmp’ which increases critical path of loop iteration. The second one is ‘cmp’ with operands of loads at the loop beginning is far enough from it’s operands in degraded case that gives two additional spills and fills. Corresponding instrumented asm code fragments of the first part of loop with comments are the following.

r229097:

0xf763e540 73 1161 movzbl (%esi),%eax
0xf763e543 74 1165 movzbl 0x1(%esi),%ebx
0xf763e547 75 1365 mov 0x2(%esi),%cl
0xf763e54a 76 1379 not %cl
0xf763e54c 77 1427 mov %al,%ch
0xf763e54e 78 1537 cmp %eax,%ebx !! 'cmp' operands are close
0xf763e550 79 1137 mov %bl,%al
0xf763e552 80 971 movzbl %cl,%ebx
0xf763e555 81 1385 not %ch
0xf763e557 82 924 not %al
0xf763e559 83 1123 jae f763e570 <t_run_test+0x150>
0xf763e55b 84 562 movzbl %ch,%ebp !! alternative-then
0xf763e55e 85 978 mov %ch,%ah !! ‘movzbl,mov,cmp’
0xf763e560 86 603 cmp %ebx,%ebp !! under condition
0xf763e562 87 548 jae f763e579 <t_run_test+0x159> !!
0xf763e564 88 590 jmp f763e57b <t_run_test+0x15b> !!
0xf763e566 89 0 nopl 0x0(%eax)
0xf763e56d 90 0 nopl (%eax)
0xf763e570 91 408 movzbl %al,%ebp !! alternative-else
0xf763e573 92 965 mov %al,%ah !! ‘movzbl,mov,cmp’
0xf763e575 93 429 cmp %ebx,%ebp !! under condition
0xf763e577 94 619 jb f763e57b <t_run_test+0x15b> !!
0xf763e579 95 637 mov %cl,%ah
0xf763e57b 96 2104 sub %ah,%ch
+++++
22017

vs.

r229099:

0xf7692540 73 933 movzbl (%esi),%eax
0xf7692543 74 1464 movzbl 0x1(%esi),%ebx
0xf7692547 75 1170 mov 0x2(%esi),%cl
0xf769254a 76 1538 not %cl
0xf769254c 77 1232 mov %al,%ch
0xf769254e 78 1542 mov %eax,0x44(%esp) !! spill-instr.
0xf7692552 79 904 mov %bl,%al
0xf7692554 80 1185 mov %ebx,0x40(%esp) !! spill-instr.
0xf7692558 81 869 movzbl %cl,%ebp
0xf769255b 82 1083 not %ch
0xf769255d 83 911 not %al
0xf769255f 84 1121 movzbl %ch,%ebx !! ‘movzbl,mov,cmp’
0xf7692562 85 920 mov %ch,%ah !! increases CRP of loop iteration
0xf7692564 86 1078 cmp %ebp,%ebx !!
0xf7692566 87 917 jb f769256a <t_run_test+0x14a>
0xf7692568 88 896 mov %cl,%ah
0xf769256a 89 1490 movzbl %al,%ebx !! ‘movzbl,mov,cmp’
0xf769256d 90 1603 cmp %ebp,%ebx !! increases CRP of loop iteration
0xf769256f 91 933 mov %al,%bl !!
0xf7692571 92 1494 jb f7692575 <t_run_test+0x155>
0xf7692573 93 677 mov %cl,%bl
0xf7692575 94 2565 mov 0x40(%esp),%ebp !! fill-instr.
0xf7692579 95 2110 cmp 0x44(%esp),%ebp !! 'cmp' operands are loads at the loop beginning
0xf769257d 96 1490 jb f7692581 <t_run_test+0x161>
0xf769257f 97 828 mov %bl,%ah
0xf7692581 98 1905 sub %ah,%ch
+++++
32858
.....................

And corresponding loop IR dump fragments “After Simplify the CFG” and “After Expand ISel Pseudo-instructions” are the following. Practically, shape of target code appears after the first machine phase.

r229097:

*** IR Dump After Simplify the CFG ***
......................................
for.body8: ; preds = %for.cond5 !! loop beg.
%incdec.ptr = getelementptr inbounds i8* %ReadPtr.0, i32 1
%7 = load i8* %ReadPtr.0, align 1, !tbaa !​8
%incdec.ptr9 = getelementptr inbounds i8* %ReadPtr.0, i32 2
%8 = load i8* %incdec.ptr, align 1, !tbaa !​8
%incdec.ptr10 = getelementptr inbounds i8* %ReadPtr.0, i32 3
%9 = load i8* %incdec.ptr9, align 1, !tbaa !​8
%10 = xor i8 %7, -1
%11 = xor i8 %8, -1
%12 = xor i8 %9, -1
%cmp21 = icmp ult i8 %8, %7
br i1 %cmp21, label %if.then23, label %if.else

if.then23: ; preds = %for.body8
%cmp26 = icmp ult i8 %10, %12 !! cmp26 is under condition
%.sink = select i1 %cmp26, i8 %10, i8 %12
br label %if.end42

if.else: ; preds = %for.body8
%cmp33 = icmp ult i8 %11, %12 !! cmp33 is under condition
%.sink86 = select i1 %cmp33, i8 %11, i8 %12
br label %if.end42

if.end42: ; preds = %if.else, %if.then23
%xk.0 = phi i8 [ %.sink, %if.then23 ], [ %.sink86, %if.else ]
%sub45 = sub i8 %10, %xk.0

..........................
..........................

*** IR Dump After Expand ISel Pseudo-instructions ***:

..........................
BB#5: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#4 BB#8
%vreg9 = PHI %vreg7, <BB#4>, %vreg18, <BB#8>; GR32:%vreg9,%vreg7,%vreg18
%vreg10 = PHI %vreg6, <BB#4>, %vreg20, <BB#8>; GR32:%vreg10,%vreg6,%vreg20
%vreg11 = PHI %vreg0, <BB#4>, %vreg19, <BB#8>; GR32:%vreg11,%vreg0,%vreg19
%vreg57 = MOVZX32rm8 %vreg11, 1, %noreg, 0, %noreg; mem:LD1%ReadPtr.0127 GR32:%vreg57,%vreg11
%vreg58 = COPY %vreg57; GR32_ABCD:%vreg58 GR32:%vreg57
%vreg59 = COPY %vreg58:sub_8bit; GR8:%vreg59 GR32_ABCD:%vreg58
%vreg60 = MOVZX32rm8 %vreg11, 1, %noreg, 1, %noreg; mem:LD1%scevgep136 GR32:%vreg60,%vreg11
%vreg61 = COPY %vreg60; GR32_ABCD:%vreg61 GR32:%vreg60
%vreg62 = COPY %vreg61:sub_8bit; GR8:%vreg62 GR32_ABCD:%vreg61
%vreg63 = MOV8rm %vreg11, 1, %noreg, 2, %noreg; mem:LD1%scevgep137 GR8:%vreg63 GR32:%vreg11
%vreg12<def,tied1> = NOT8r %vreg59; GR8:%vreg12,%vreg59
%vreg13<def,tied1> = NOT8r %vreg62; GR8:%vreg13,%vreg62
%vreg14<def,tied1> = NOT8r %vreg63; GR8:%vreg14,%vreg63
%vreg64<def,tied1> = SUB32rr %vreg60, %vreg57, %EFLAGS; GR32:%vreg64,%vreg60,%vreg57
JAE_1 <BB#7>, %EFLAGS
JMP_1 <BB#6>
Successors according to CFG: BB#6(16) BB#7(16)

BB#6: derived from LLVM BB %if.then23
Predecessors according to CFG: BB#5
%vreg68 = MOVZX32rr8 %vreg14; GR32:%vreg68 GR8:%vreg14
%vreg69 = MOVZX32rr8 %vreg12; GR32:%vreg69 GR8:%vreg12
%vreg70<def,tied1> = SUB32rr %vreg69, %vreg68, %EFLAGS; GR32:%vreg70,%vreg69,%vreg68
JB_1 <BB#17>, %EFLAGS
Successors according to CFG: BB#16 BB#17

BB#16: derived from LLVM BB %if.then23
Predecessors according to CFG: BB#6
Successors according to CFG: BB#17

BB#17: derived from LLVM BB %if.then23
Predecessors according to CFG: BB#6 BB#16
%vreg15 = PHI %vreg14, <BB#16>, %vreg12, <BB#6>; GR8:%vreg15,%vreg14,%vreg12
JMP_1 <BB#8>
Successors according to CFG: BB#8

BB#7: derived from LLVM BB %if.else
Predecessors according to CFG: BB#5
%vreg65 = MOVZX32rr8 %vreg14; GR32:%vreg65 GR8:%vreg14
%vreg66 = MOVZX32rr8 %vreg13; GR32:%vreg66 GR8:%vreg13
%vreg67<def,tied1> = SUB32rr %vreg66, %vreg65, %EFLAGS; GR32:%vreg67,%vreg66,%vreg65
JB_1 <BB#19>, %EFLAGS
Successors according to CFG: BB#18 BB#19

vs.

r229099:

*** IR Dump After Simplify the CFG ***
......................................
for.body8: ; preds = %for.cond5 !! loop beg.
%incdec.ptr = getelementptr inbounds i8* %ReadPtr.0, i32 1
%7 = load i8* %ReadPtr.0, align 1, !tbaa !​8
%incdec.ptr9 = getelementptr inbounds i8* %ReadPtr.0, i32 2
%8 = load i8* %incdec.ptr, align 1, !tbaa !​8
%incdec.ptr10 = getelementptr inbounds i8* %ReadPtr.0, i32 3
%9 = load i8* %incdec.ptr9, align 1, !tbaa !​8
%10 = xor i8 %7, -1
%11 = xor i8 %8, -1
%12 = xor i8 %9, -1
%cmp21 = icmp ult i8 %8, %7
%cmp26 = icmp ult i8 %10, %12 !! cmp26 becomes unconditional/speculative
%.sink = select i1 %cmp26, i8 %10, i8 %12
%cmp33 = icmp ult i8 %11, %12 !! cmp33 becomes unconditional/speculative
%.sink86 = select i1 %cmp33, i8 %11, i8 %12
%xk.0 = select i1 %cmp21, i8 %.sink, i8 %.sink86 !! additional select depended on the first 'cmp21'
!! and two another selects
%sub45 = sub i8 %10, %xk.0

..........................
..........................

*** IR Dump After Expand ISel Pseudo-instructions ***:

..........................
BB#5: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#4 BB#18
%vreg9 = PHI %vreg7, <BB#4>, %vreg12, <BB#18>; GR32:%vreg9,%vreg7,%vreg12
%vreg10 = PHI %vreg6, <BB#4>, %vreg14, <BB#18>; GR32:%vreg10,%vreg6,%vreg14
%vreg11 = PHI %vreg0, <BB#4>, %vreg13, <BB#18>; GR32:%vreg11,%vreg0,%vreg13
%vreg51 = MOVZX32rm8 %vreg11, 1, %noreg, 0, %noreg; mem:LD1%ReadPtr.0127 GR32:%vreg51,%vreg11
%vreg52 = COPY %vreg51; GR32_ABCD:%vreg52 GR32:%vreg51
%vreg53 = COPY %vreg52:sub_8bit; GR8:%vreg53 GR32_ABCD:%vreg52
%vreg54 = MOVZX32rm8 %vreg11, 1, %noreg, 1, %noreg; mem:LD1%scevgep136 GR32:%vreg54,%vreg11
%vreg55 = COPY %vreg54; GR32_ABCD:%vreg55 GR32:%vreg54
%vreg56 = COPY %vreg55:sub_8bit; GR8:%vreg56 GR32_ABCD:%vreg55
%vreg57 = MOV8rm %vreg11, 1, %noreg, 2, %noreg; mem:LD1%scevgep137 GR8:%vreg57 GR32:%vreg11
%vreg58<def,tied1> = NOT8r %vreg53; GR8:%vreg58,%vreg53
%vreg59<def,tied1> = NOT8r %vreg56; GR8:%vreg59,%vreg56
%vreg60<def,tied1> = NOT8r %vreg57; GR8:%vreg60,%vreg57
%vreg61 = MOVZX32rr8 %vreg58; GR32:%vreg61 GR8:%vreg58
%vreg62 = MOVZX32rr8 %vreg60; GR32:%vreg62 GR8:%vreg60
%vreg63<def,tied1> = SUB32rr %vreg61, %vreg62, %EFLAGS; GR32:%vreg63,%vreg61,%vreg62
JB_1 <BB#14>, %EFLAGS
Successors according to CFG: BB#13 BB#14

BB#13: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#5
Successors according to CFG: BB#14

BB#14: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#5 BB#13
%vreg64 = PHI %vreg60, <BB#13>, %vreg58, <BB#5>; GR8:%vreg64,%vreg60,%vreg58
%vreg65 = MOVZX32rr8 %vreg59; GR32:%vreg65 GR8:%vreg59
%vreg66<def,tied1> = SUB32rr %vreg65, %vreg62, %EFLAGS; GR32:%vreg66,%vreg65,%vreg62
JB_1 <BB#16>, %EFLAGS
Successors according to CFG: BB#15 BB#16

BB#15: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#14
Successors according to CFG: BB#16

BB#16: derived from LLVM BB %for.body8
Predecessors according to CFG: BB#14 BB#15
%vreg67 = PHI %vreg60, <BB#15>, %vreg59, <BB#14>; GR8:%vreg67,%vreg60,%vreg59
%vreg68<def,tied1> = SUB32rr %vreg54, %vreg51, %EFLAGS; GR32:%vreg68,%vreg54,%vreg51
JB_1 <BB#18>, %EFLAGS
Successors according to CFG: BB#17 BB#18

Okunev Sergey,
Software Engineer
Intel Compiler Team

[llvmbot]

eembc_2_0/mp4decodedata4:

The performance gap of this test between versions r229097 and r229099 falls on function ‘transfer_16to8add_c’ as seen in comparative fuction statistics.
r229097
| r229099
| |
.............................................................
Total 12450 100.00% 12899 +3.48% !!
idct_int32 4399 35.33% 4324 -0.58%
transfer_16to8add_c 1342 10.78% 1746 +3.13% !!
dequant_inter_c 1713 13.76% 1652 -0.47%
get_coeff 1225 9.84% 1286 +0.47%

The function ‘transfer_16to8add_c’ has single hottest loop with 8 similar parts (from fully unroll innermost loop) consisting of two level if-statements. And for each loop part more aggressive applying of “Simplify the CFG” and deleting of outer level of if-statement leads to cancel enabling ‘cmov’ instruction for simple innermost if-statement and increasing of the number of instructions for evaluating stored value on CF joint point. Corresponding instrumented asm code fragments of the first part of loop with comments are the following.

r229097:

0xf75fe1b0 12 21 movzbl -0x7(%edx),%ebx
0xf75fe1b4 13 28 add (%ecx,%esi,1),%bx
0xf75fe1b8 14 12 js f75fe1d0 <transfer_16to8add_c+0x40>
0xf75fe1ba 15 18 movswl %bx,%ebx
0xf75fe1bd 16 23 cmp $0xff,%ebx
0xf75fe1c3 17 14 cmovg %di,%bx !! 'iselect' is transformed to 'cmov' for innermost if.
0xf75fe1c7 18 51 jmp f75fe1d2 <transfer_16to8add_c+0x42> !!
0xf75fe1c9 19 0 nopl 0x0(%eax)
0xf75fe1d0 20 0 xor %ebx,%ebx
0xf75fe1d2 21 10 mov %bl,-0x7(%edx) !! less instr. on CRP to store
+++
177
vs.

r229099:

0xf76622a0 12 17 movzbl -0x7(%edx),%ebx
0xf76622a4 13 20 movb $0xff,0x3(%esp) !! additional spill instr.
0xf76622a9 14 14 add (%ecx,%esi,1),%bx
0xf76622ad 15 16 movswl %bx,%eax
0xf76622b0 16 22 cmp $0xff,%eax
0xf76622b5 17 26 mov $0xff,%al
0xf76622b7 18 31 jg f76622bb <transfer_16to8add_c+0x3b> !! innermost if-stmt. is not converted to cmov
0xf76622b9 19 15 mov %bl,%al
0xf76622bb 20 25 test %bx,%bx
0xf76622be 21 15 mov $0x0,%ebx
0xf76622c3 22 14 js f76622c7 <transfer_16to8add_c+0x47>
0xf76622c5 23 15 mov %al,%bl
0xf76622c7 24 14 mov %bl,-0x7(%edx) !! more instr. on CRP to store
+++
244

And corresponding loop IR dump fragments “After Simplify the CFG” and “After Expand ISel Pseudo-instructions” are the following. Two DF depended ‘select’ instructions in r229099 case are not expanded in cmov at all that leads to performance drawback mentioned above.

r229097:

*** IR Dump After Simplify the CFG ***
......................................
for.body3:
.........
%1 = load i16* %arrayidx7, align 2, !tbaa !​5
%add9 = add i16 %conv4, %1
%cmp12 = icmp slt i16 %add9, 0
br i1 %cmp12, label %if.end18, label %if.else

if.else: ; preds = %for.body3
%cmp15 = icmp sgt i16 %add9, 25 %.add9 = select i1 %cmp15, i16 255, i16 %add9
%.add9 = select i1 %cmp15, i16 255, i16 %add9
br label %if.end18

if.end18: ; preds = %if.else, %for.body3
%transfer_pixel.0 = phi i16 [ 0, %for.body3 ], [ %.add9, %if.else ]
%conv19 = trunc i16 %transfer_pixel.0 to i8
store i8 %conv19, i8* %arrayidx, align 1, !tbaa !​2
%inc = add i32 %i.0, 1
br label %for.cond1
.................

vs.

r229099:

*** IR Dump After Simplify the CFG ***
......................................
for.body3:
.........
.........
%1 = load i16* %arrayidx7, align 2, !tbaa !​5
%add9 = add i16 %conv4, %1
%cmp12 = icmp slt i16 %add9, 0
%cmp15 = icmp sgt i16 %add9, 255
%.add9 = select i1 %cmp15, i16 255, i16 %add9 !! select -> select
%transfer_pixel.0 = select i1 %cmp12, i16 0, i16 %.add9 !! is not transformed to cmov at all
%conv19 = trunc i16 %transfer_pixel.0 to i8
store i8 %conv19, i8* %arrayidx, align 1, !tbaa !​2
%inc = add i32 %i.0, 1
br label %for.cond1
.....................

[jmolloy]

Hi,

Thanks for the analysis. So unless I'm mistaken, the problem is that the X86 backend (or CGP) doesn't correctly lower that select to cmov, and converts it to a jump-sequence instead?

Cheers,

James

[llvmbot]

Hi,

Thanks for the analysis. So unless I'm mistaken, the problem is that the X86
backend (or CGP) doesn't correctly lower that select to cmov, and converts
it to a jump-sequence instead?

Cheers,

James

Hi,

The problem is deeper. Conversion of ‘select’ to ‘cmov’ is concerned on second case (mp4decode) only and is not the main root of degradations.
Common problem is transforming of control flow realized through branches to ‘select’ instructions with DF dependencies changes the operation properties too, - from conditional under branch condition to “speculative”/unconditional without dependence/link to condition (see comments of asm codes of the first case). Therefore, the transformation is 1) not safety in terms of interruptions and 2) multiple-valued transformation, especially, in case of nested if-statements, that we see for both cases, - reverse transformation/expansion of ‘selects’ to machine form with branches leads to other shape of control flow graph with nonoptimal critical paths, with speculative overheads.

Regards,
Sergey

[hfinkel]

Hi,

Thanks for the analysis. So unless I'm mistaken, the problem is that the X86
backend (or CGP) doesn't correctly lower that select to cmov, and converts
it to a jump-sequence instead?

Cheers,

James

Hi,

The problem is deeper. Conversion of ‘select’ to ‘cmov’ is concerned on
second case (mp4decode) only and is not the main root of degradations.
Common problem is transforming of control flow realized through branches to
‘select’ instructions with DF dependencies changes the operation properties
too, - from conditional under branch condition to
“speculative”/unconditional without dependence/link to condition (see
comments of asm codes of the first case). Therefore, the transformation is

1. not safety in terms of interruptions

James, are we no longer checking isSafeToSpeculativelyExecute when forming the selects? If not, we need to do that.

and 2) multiple-valued
transformation, especially, in case of nested if-statements, that we see for
both cases, - reverse transformation/expansion of ‘selects’ to machine form
with branches leads to other shape of control flow graph with nonoptimal
critical paths, with speculative overheads.

Is this because it does not 're-sink' the computations back into the conditionally-executed blocks?

Regards,
Sergey

[jmolloy]

Hi Hal,

There was actually very little code change here. isSafeToSpeculativelyExecute() is still checked in all the right places as far as I can see, but it is possible there is a latent bug somewhere.

The only function that changed was ComputeSpeculationCost(), which is seemingly called after isSafeToSpeculativelyExecute() returns true.

Cheers,

James

[hfinkel]

Hi Hal,

There was actually very little code change here.
isSafeToSpeculativelyExecute() is still checked in all the right places as
far as I can see, but it is possible there is a latent bug somewhere.

The only function that changed was ComputeSpeculationCost(), which is
seemingly called after isSafeToSpeculativelyExecute() returns true.

Okay, that's what I though. The transformation, then, should be "safe", at least from the IR perspective (modulo bugs in isSafeToSpeculativelyExecute, of course).

Cheers,

James

[llvmbot]

.......

and 2) multiple-valued
transformation, especially, in case of nested if-statements, that we see for
both cases, - reverse transformation/expansion of ‘selects’ to machine form
with branches leads to other shape of control flow graph with nonoptimal
critical paths, with speculative overheads.

Is this because it does not 're-sink' the computations back into the
conditionally-executed blocks?

I would say that NOT all computations return into the conditionally-executed blocks. E.g., for eembc_2_0/rgbcmykv2 the transformation to selects and back in r229099 case looks as follows in terms of source code.

Source code:

 /* Calculate black content (min of C, M, and Y.) */
 if (xc < xm)  
 { 
     xk = (xc < xy ? xc : xy);
 } else
 {
     xk = (xm < xy ? xm : xy);
 }

r229099. “After Expand ISel Pseudo-instructions” in terms src:

  xk = xc;
  if (xc > xy) 
  { 
      xk = xy:         
  }   
  tmp = xm;
  if (xm > xy)
  {
      tmp = xy:
  }   

  if (xc > xm)
  {
      xk = tmp;
  }

Thus, there are two conditions on every control flow path in initial form and there are three conditions on every control flow path in second case. And the number of branches on control flow paths differs too.

Sergey

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#43205