[X86] Apply SlowIncDec feature to Sandybridge/Ivybridge CPUs as well

[craig.topper]

Summary

Currently we start applying this on Haswell and newer. I don't believe anything changed in the Haswell architecture to make this the right cutoff point. The partial flag handling around this has been roughly the same since Sandybridge.

gcc seems to disable inc/dec all the way back to at least core2. We could do the same if we want.

[chandlerc]

I'm fine with this, but it would be good to get confirmation that there is a genuine partial flag update stall issue we're avoiding with this... As long as you all can confirm that this is a real issue even on modern processors, then all this makes sense. =D

[craig.topper]

I think Pentium 4 and Silvermont read the old CF value and pass it through the INC/DEC instruction.

I think the "core" line prior to Sandy Bridge any instruction that reads the CF flag after INC/DEC experienced a stall until the INC/DEC instruction retired.

I think from Sandy Bridge onward, it is no longer a stall until retirement, but an instruction that reads the CF flag after INC/DEC become dependent on the last writer of CF before the INC/DEC.

[chandlerc]

In D37250#855662, @craig.topper wrote:

I think Pentium 4 and Silvermont read the old CF value and pass it through the INC/DEC instruction.

I think the "core" line prior to Sandy Bridge any instruction that reads the CF flag after INC/DEC experienced a stall until the INC/DEC instruction retired.

I think from Sandy Bridge onward, it is no longer a stall until retirement, but an instruction that reads the CF flag after INC/DEC become dependent on the last writer of CF before the INC/DEC.

Is it only an instruction that reads the *CF* flag?

Because if so, then we might want to drop this entirely... If an instruction read the CF flag after INC/DEC, either some other instruction def'ed the flag for that read killing the dependency, it is *trying* to read CF from a previous instruction in a fit of cleverness, or it is just buggy code... In any case, the dependency doesn't seem like a problem?

(Or maybe we get "false" dependencies because of how this is implemented inside the chip?)

[chandlerc]

Put differently, maybe we only want this on processors *older* than sandybridge... but today, we don't. and we don't have a lot of tuning for older processors... so maybe we should just nuke it going forward.

[craig.topper]

There is definitely a false dependency issue that can be triggered by "shift CL" because variables shifts are defined to not update any flags if CL is 0, but the shift value isn't know until it executes so the shift is dependent on the old flags including CF

[chandlerc]

In D37250#855671, @craig.topper wrote:

There is definitely a false dependency issue that can be triggered by "shift CL" because variables shifts are defined to not update any flags if CL is 0, but the shift value isn't know until it executes so the shift is dependent on the old flags including CF

That sounds bad regardless of inc/dec though -- should it just be handled by a flag-clearing instruction to break the dependency? (Either something like xorl %eax, %eax or orl %eax, %eax depending on whether there is a dead register...)

[craig.topper]

From HSW on we should be using SHLX/SHRX/SARX instead of any "shift CL" to avoid this silliness. Those instruction don't update flags.

'xor' would definitely break the dependency. 'or' would turn the flag dependency into a register dependency so that's not really better.

lib/Target/X86/X86.td

def SNBFeatures : ProcessorFeatures<[], [
   FeatureAES,
   FeatureSlowDivide64,
   FeaturePCLMUL,
   FeatureXSAVE,
   FeatureXSAVEOPT,
   FeatureLAHFSAHF,
   FeatureSlow3OpsLEA,
   FeatureFastScalarFSQRT,
-  FeatureFastSHLDRotate
+  FeatureFastSHLDRotate,
+  FeatureSlowIncDec
 ]>;
 
 class SandyBridgeProc<string Name> : ProcModel<Name, SandyBridgeModel,
                                                SNBFeatures.Value, [
   FeatureSlowBTMem,
   FeatureSlowUAMem32
 ]>;
 def : SandyBridgeProc<"sandybridge">;

 
 def HSWFeatures : ProcessorFeatures<IVBFeatures.Value, [
   FeatureAVX2,
   FeatureBMI,
   FeatureBMI2,
   FeatureERMSB,
   FeatureFMA,
   FeatureLZCNT,
-  FeatureMOVBE,
-  FeatureSlowIncDec
+  FeatureMOVBE
 ]>;
 
 class HaswellProc<string Name> : ProcModel<Name, HaswellModel,
                                            HSWFeatures.Value, []>;
 def : HaswellProc<"haswell">;
 def : HaswellProc<"core-avx2">; // Legacy alias.
 
 def BDWFeatures : ProcessorFeatures<HSWFeatures.Value, [

test/CodeGen/X86/misched-fusion.ll

-; RUN: llc < %s -mtriple=x86_64-- -mcpu=corei7-avx -disable-lsr -pre-RA-sched=source -enable-misched -verify-machineinstrs | FileCheck %s
+; RUN: llc < %s -mtriple=x86_64-- -mattr=avx -disable-lsr -pre-RA-sched=source -enable-misched -verify-machineinstrs | FileCheck %s
 
 ; Verify that TEST+JE are scheduled together.
 ; CHECK: test_je
 ; CHECK: %loop
 ; CHECK: test
 ; CHECK-NEXT: je
 define void @test_je() {
 entry:

test/CodeGen/X86/rdrand.ll

 ; X86-NEXT:  # BB#1: # %while.body.preheader
 ; X86-NEXT:    movl {{[0-9]+}}(%esp), %ecx
 ; X86-NEXT:    .p2align 4, 0x90
 ; X86-NEXT:  .LBB3_2: # %while.body
 ; X86-NEXT:    # =>This Inner Loop Header: Depth=1
 ; X86-NEXT:    rdrandl %edx
 ; X86-NEXT:    movl %edx, (%ecx)
 ; X86-NEXT:    leal 4(%ecx), %ecx
-; X86-NEXT:    decl %eax
+; X86-NEXT:    addl $-1, %eax
 ; X86-NEXT:    jne .LBB3_2
 ; X86-NEXT:  .LBB3_3: # %while.end
 ; X86-NEXT:    retl
 ;
 ; X64-LABEL: loop:
 ; X64:       # BB#0: # %entry
 ; X64-NEXT:    testl %esi, %esi
 ; X64-NEXT:    je .LBB3_2
 ; X64-NEXT:    .p2align 4, 0x90
 ; X64-NEXT:  .LBB3_1: # %while.body
 ; X64-NEXT:    # =>This Inner Loop Header: Depth=1
 ; X64-NEXT:    rdrandl %eax
 ; X64-NEXT:    movl %eax, (%rdi)
 ; X64-NEXT:    leaq 4(%rdi), %rdi
-; X64-NEXT:    decl %esi
+; X64-NEXT:    addl $-1, %esi
 ; X64-NEXT:    jne .LBB3_1
 ; X64-NEXT:  .LBB3_2: # %while.end
 ; X64-NEXT:    retq
 entry:
   %tobool1 = icmp eq i32 %n, 0
   br i1 %tobool1, label %while.end, label %while.body
 
 while.body:                                       ; preds = %entry, %while.body