[X86] Remove FeatureSlowIncDec from Sandy Bridge and later Intel Core CPUs

[craig.topper]

Summary

Inc and Dec were at one point slow on Intel CPUs due to their tendency to cause partial flag stalls on P6 derived CPU cores. This is because these instructions are defined to preserve the carry flag. This partial flag stall issue persisted until Sandy Bridge when flag merging was changed to be handled as a data dependency instead of as a stall until retirement. Sandy Bridge and later CPUs rename the C flag separately from OSPAZ so there is no flag merge needed on INC/DEC to preserve the C flag.

Given these improvements I don't know why INC/DEC was ever considered slow on Sandy Bridge. If anything they should have been disabled on the earlier CPUs instead.

Note after this patch, INC/DEC are still considered slow on Silvermont, Goldmont, Knights Landing and our generic "x86-64" CPU.

[spatel]

Should we change the generic model too then since most CPUs prefer inc/dec?
I'm guessing that's a lot more test diffs, so no problem to make it another patch, but just want to know if that's the way to think about the generic model.

[craig.topper]

In D58412#1403190, @spatel wrote:

Should we change the generic model too then since most CPUs prefer inc/dec?
I'm guessing that's a lot more test diffs, so no problem to make it another patch, but just want to know if that's the way to think about the generic model.

Related question to that. Should "pentium4" which is clang's Linux default CPU for 32-bit builds have more tuning flags on it?

[spatel]

In D58412#1403230, @craig.topper wrote:

In D58412#1403190, @spatel wrote:

Should we change the generic model too then since most CPUs prefer inc/dec?
I'm guessing that's a lot more test diffs, so no problem to make it another patch, but just want to know if that's the way to think about the generic model.

Related question to that. Should "pentium4" which is clang's Linux default CPU for 32-bit builds have more tuning flags on it?

I've never looked at how the 32-bit setting works...or at least I can't remember it now. :)
But that sounds weird. Shouldn't we have a generic 32-bit model similar to the generic 64-bit model?

[chandlerc]

LGTM

I think we can consider tweaking the generic ones separately.

FWIW, I would be in favor of dropping this from x86-64.

Also FWIW, I would be in favor of making i686 (or a better spelling if someone wants to suggest one such as x86-32?) a thing similar to x86-64, and I'd be happy to see them follow along in similar ways of "as good as we can do for modern CPUs but supporting a particular baseline".

llvm/trunk/lib/Target/X86/X86.td

def SNBFeatures : ProcessorFeatures<[], [
   FeatureSlowDivide64,
   FeaturePCLMUL,
   FeatureXSAVE,
   FeatureXSAVEOPT,
   FeatureLAHFSAHF,
   FeatureSlow3OpsLEA,
   FeatureFastScalarFSQRT,
   FeatureFastSHLDRotate,
-  FeatureSlowIncDec,
   FeatureMergeToThreeWayBranch,
   FeatureMacroFusion
 ]>;
 
 class SandyBridgeProc<string Name> : ProcModel<Name, SandyBridgeModel,
                                                SNBFeatures.Value, [
   FeatureSlowUAMem32,
   FeaturePOPCNTFalseDeps

llvm/trunk/test/CodeGen/X86/mul-constant-result.ll

 ; X64-HSW:       # %bb.0:
 ; X64-HSW-NEXT:    # kill: def $edi killed $edi def $rdi
 ; X64-HSW-NEXT:    cmpl $1, %esi
 ; X64-HSW-NEXT:    movl $1, %ecx
 ; X64-HSW-NEXT:    movl %esi, %eax
 ; X64-HSW-NEXT:    cmovgl %ecx, %eax
 ; X64-HSW-NEXT:    testl %esi, %esi
 ; X64-HSW-NEXT:    cmovel %ecx, %eax
-; X64-HSW-NEXT:    addl $-1, %edi
+; X64-HSW-NEXT:    decl %edi
 ; X64-HSW-NEXT:    cmpl $31, %edi
 ; X64-HSW-NEXT:    ja .LBB0_36
 ; X64-HSW-NEXT:  # %bb.1:
 ; X64-HSW-NEXT:    jmpq *.LJTI0_0(,%rdi,8)
 ; X64-HSW-NEXT:  .LBB0_2:
 ; X64-HSW-NEXT:    addl %eax, %eax
 ; X64-HSW-NEXT:    # kill: def $eax killed $eax killed $rax
 ; X64-HSW-NEXT:    retq

llvm/trunk/test/CodeGen/X86/rdrand.ll

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