[LICM] Code Hygiene - rip out sinkCondFail

[shajrawi]

radar rdar://problem/40073634

Removing this optimization from SIL: It is not worth the extra code complexity and compilation time.

More in-depth explanation for the reasoning behind my decision:

1. What is being done there is obviously not LICM (more below) - even if it is useful it should be its own separate optimization
2. The regression that caused us to add this code is no longer there in most cases - 10% in only one specific corner-case
3. Even if the regression was still there, this is an extremely specific code pattern that we are pattern-matching against. Said pattern would be hard to find in any real code.

There is a small code snippet in rdar://17451529 that caused us to add this optimization. Looking at it now we see that the only difference is in loop1 example -

The only difference in SIL level is in loop 1:
%295 = tuple_extract %294 : $(Builtin.Int64, Builtin.Int1), 0
%296 = tuple_extract %294 : $(Builtin.Int64, Builtin.Int1), 1
cond_fail %296 : $Builtin.Int1
%298 = struct $Int (%295 : $Builtin.Int64)
store %298 to %6 : $*Int
%300 = builtin "cmp_eq_Int64"(%292 : $Builtin.Int64, %16 : $Builtin.Int64) : $Builtin.Int1
cond_br %300, bb1, bb12

The cond_fail instruction in said loop is moved below the store instruction / above the builtin.

Looking at the resulting IR. And how LLVM optimizes it. It is almost the same.

If we look at the assembly code being executed then, before removing this optimization, we have:
LBB0_11:
testq %rcx, %rcx
je LBB0_2
decq %rcx
incq %rax
movq %rax, _$S4main4sum1Sivp(%rip)
jno LBB0_11

After removing it we have:
LBB0_11:
incq %rax
testq %rcx, %rcx
je LBB0_2
decq %rcx
movq %rax, %rdx
incq %rdx
jno LBB0_11

There is no extra load/movq which was mentioned the radar.

[shajrawi]

Per @atrick comments in PR #17194 , merging this commit to master

[shajrawi]

@swift-ci Please smoke test and merge