because we were checking the wrong thing.  Thanks to andrew for pointing
this out!

llvm-svn: 20554

llvm-svn: 20552

llvm-svn: 20542

numbering values in live ranges for physical registers.

The alpha backend currently generates code that looks like this:

  vreg = preg
...
  preg = vreg
  use preg
...
  preg = vreg
  use preg

etc.  Because vreg contains the value of preg coming in, each of the
copies back into preg contain that initial value as well.

In the case of the Alpha, this allows this testcase:

void "foo"(int %blah) {
        store int 5, int *%MyVar
        store int 12, int* %MyVar2
        ret void
}

to compile to:

foo:
        ldgp $29, 0($27)
        ldiq $0,5
        stl $0,MyVar
        ldiq $0,12
        stl $0,MyVar2
        ret $31,($26),1

instead of:

foo:
        ldgp $29, 0($27)
        bis $29,$29,$0
        ldiq $1,5
        bis $0,$0,$29
        stl $1,MyVar
        ldiq $1,12
        bis $0,$0,$29
        stl $1,MyVar2
        ret $31,($26),1

This does not seem to have any noticable effect on X86 code.

This fixes PR535.

llvm-svn: 20536

llvm-svn: 20535

This allows the alpha backend to compile:

bool %test(uint %P) {
        %c = seteq uint %P, 0
        ret bool %c
}

into:

test:
        ldgp $29, 0($27)
        ZAP $16,240,$0
        CMPEQ $0,0,$0
        AND $0,1,$0
        ret $31,($26),1

instead of:

test:
        ldgp $29, 0($27)
        ZAP $16,240,$0
        ldiq $1,0
        ZAP $1,240,$1
        CMPEQ $0,$1,$0
        AND $0,1,$0
        ret $31,($26),1

... and fixes PR534.

llvm-svn: 20534

llvm-svn: 20533

that Alkis found with Java, thanks Alkis!

llvm-svn: 20531

Patch contributed by Vladimir Merzliakov.

llvm-svn: 20529

llvm-svn: 20527

llvm-svn: 20525

llvm-svn: 20523

to cygwin)

llvm-svn: 20520

struct types.  This fixes Regression/CodeGen/CBackend/2005-03-08-RecursiveTypeCrash.ll,
a crash on Java output that Alkis reported.

llvm-svn: 20519

llvm-svn: 20515

llvm-svn: 20507

llvm-svn: 20506

hopefully not breaking too many other things.

llvm-svn: 20505

llvm-svn: 20501

llvm-svn: 20497

llvm-svn: 20494

a nested loop.  This fixes Transforms/LoopUnroll/2005-03-06-BadLoopInfoUpdate.ll
and PR532

llvm-svn: 20493

llvm-svn: 20484

llvm-svn: 20483

Speed up the symbol stripping code by avoiding a linear search of the
type table.

Get rid of removeEntry(type_iterator), since 'remove' is exactly the same
operation.

llvm-svn: 20481

llvm-svn: 20479

InternallyInconsistent is always false.

llvm-svn: 20477

llvm-svn: 20476

llvm-svn: 20474

llvm-svn: 20472

llvm-svn: 20471

The problem is that Function::renameLocalSymbols is iterating through
the symbol table planes, occasionally calling setName to rename a value
(which used to do a symbol table remove/insert pair).

The problem is that if there is only a single value in a particular type
plane that the remove will nuke the symbol table plane, and the insert
will create and insert a new one.  This hoses Function::renameLocalSymbols
because it has an iterator to the old plane, under the (very reasonable)
assumption that simply renaming a value won't cause the type plane to
disappear.

This patch fixes the bug by making the rename operation a single atomic
operation, which has a side effect of making the whole thing faster too. :)

llvm-svn: 20469

llvm-svn: 20467

llvm-svn: 20466

Value::setName, which is no longer virtual.

llvm-svn: 20464

llvm-svn: 20463

llvm-svn: 20462

llvm-svn: 20461

llvm-svn: 20460

llvm-svn: 20459