llvm-svn: 25853

caused several test failures.

llvm-svn: 25852

llvm-svn: 25851

llvm-svn: 25849

bool %test(int %X) {
  %Y = seteq int %X, 13
  ret bool %Y
}

as

_test:
        addi r2, r3, -13
        cntlzw r2, r2
        srwi r3, r2, 5
        blr

rather than

_test:
        cmpwi cr7, r3, 13
        mfcr r2
        rlwinm r3, r2, 31, 31, 31
        blr

This has very little effect on most code, but speeds up analyzer 23% and
mason 11%

llvm-svn: 25848

llvm-svn: 25847

llvm-svn: 25846

llvm-svn: 25845

llvm-svn: 25844

llvm-svn: 25843

llvm-svn: 25842

llvm-svn: 25841

an operand that contains the condcode), making things significantly simpler.

llvm-svn: 25840

a CC as an operand.  Much smaller, much happier.

llvm-svn: 25839

llvm-svn: 25838

llvm-svn: 25837

llvm-svn: 25836

llvm-svn: 25835

llvm-svn: 25834

void %X(int %A) {
        %C = setlt int %A, 123          ; <bool> [#uses=1]
        br bool %C, label %T, label %F

T:              ; preds = %0
        call int %main( int 0 )         ; <int>:0 [#uses=0]
        ret void

F:              ; preds = %0
        ret void
}

to this:

X:
        save -96, %o6, %o6
        subcc %i0, 122, %l0
        bg .LBBX_2      ! F
        nop
...

not this:

X:
        save -96, %o6, %o6
        sethi 0, %l0
        or %g0, 1, %l1
        subcc %i0, 122, %l2
        bg .LBBX_4      !
        nop
.LBBX_3:        !
        or %g0, %l0, %l1
.LBBX_4:        !
        subcc %l1, 0, %l0
        bne .LBBX_2     ! F
        nop

llvm-svn: 25833

llvm-svn: 25832

llvm-svn: 25831

llvm-svn: 25830

llvm-svn: 25829

llvm-svn: 25828

int %test_cpuid(int %op) {
        %B = alloca int
        %C = alloca int
        %D = alloca int
        %A = call int asm "cpuid", "=eax,==ebx,==ecx,==edx,eax"(int* %B, int* %C, int* %D, int %op)
        %Bv = load int* %B
        %Cv = load int* %C
        %Dv = load int* %D
        %x = add int %A, %Bv
        %y = add int %x, %Cv
        %z = add int %y, %Dv
        ret int %z
}

to this:

_test_cpuid:
        sub %ESP, 16
        mov DWORD PTR [%ESP], %EBX
        mov %EAX, DWORD PTR [%ESP + 20]
        cpuid
        mov DWORD PTR [%ESP + 8], %ECX
        mov DWORD PTR [%ESP + 12], %EBX
        mov DWORD PTR [%ESP + 4], %EDX
        mov %ECX, DWORD PTR [%ESP + 12]
        add %EAX, %ECX
        mov %ECX, DWORD PTR [%ESP + 8]
        add %EAX, %ECX
        mov %ECX, DWORD PTR [%ESP + 4]
        add %EAX, %ECX
        mov %EBX, DWORD PTR [%ESP]
        add %ESP, 16
        ret

... note the proper register allocation.  :)

it is unclear to me why the loads aren't folded into the adds.

llvm-svn: 25827

llvm-svn: 25826

llvm-svn: 25825

the order of the compare operands and generate SETOGT, SETOGE, SETUGE, and
SETULE instead.

llvm-svn: 25824

generate SETULT instead.

llvm-svn: 25823

llvm-svn: 25822

a chance to custom legalize setcc, which broke a bunch of C++ Codes.
Testcase here: CodeGen/X86/2006-01-30-LongSetcc.ll

llvm-svn: 25821

llvm-svn: 25820

llvm-svn: 25819

llvm-svn: 25818

conversions. SSE does not have instructions to handle these tasks.

llvm-svn: 25817

llvm-svn: 25816

SPARC condition codes, not in terms of the DAG condcodes.  This allows us to
write nice clean patterns for cmovs/branches.

llvm-svn: 25815

uint %test(uint %X) {
        %Y = call uint %llvm.ctpop.i32(uint %X)
        ret uint %Y
}

to:

test:
        save -96, %o6, %o6
        sll %i0, 0, %l0
        popc %l0, %i0
        restore %g0, %g0, %g0
        retl
        nop

instead of to 40 logical ops.  Note the shift-by-zero that clears the top
part of the 64-bit V9 register.

Testcase here: CodeGen/SparcV8/ctpop.ll

llvm-svn: 25814

llvm-svn: 25813