you have something like i16 = truncate i64.  This fixes Regression/C/casts

llvm-svn: 21073

types.  This occurs when casting short to long on PPC for example.

llvm-svn: 21072

(which may or be function pointers) in the asmprinter. For the moment,
this changes nothing, except the IA64 backend which can use this to write:

  data8.ua  @fptr(blah__blah__mangled_function_name)

  (by setting FunctionAddrPrefix/Suffix to "@fptr(" / ")")

llvm-svn: 21024

llvm-svn: 21014

llvm-svn: 21013

llvm-svn: 21011

dont' regen the whole dag if unneccesary.  Second, fix and ugly bug with
the _PARTS nodes that caused legalize to produce multiples of them.
Finally, implement initial support for FABS and FNEG.  Currently FNEG is
the only one to be trusted though.

llvm-svn: 21009

llvm-svn: 21008

llvm-svn: 21004

llvm-svn: 21002

llvm-svn: 21001

llvm-svn: 20999

llvm-svn: 20994

Teach the SelectionDAG code how to expand and promote it
Have PPC32 LowerCallTo generate ISD::UNDEF for int arg regs used up by fp
  arguments, but not shadowing their value.  This allows us to do the right
  thing with both fixed and vararg floating point arguments.

llvm-svn: 20988

llvm-svn: 20976

llvm-svn: 20965

them up after the code has been emitted.  This allows targets to select one
mbb as multiple mbb's as needed.

llvm-svn: 20937

returned integer values all of the way to 64-bits (we only did it to 32-bits
leaving the top bits undefined).  This causes problems for targets like alpha
whose ABI's define the top bits too.

llvm-svn: 20926

llvm-svn: 20901

llvm-svn: 20900

llvm-svn: 20842

Bill Wendling!!

llvm-svn: 20649

using Function::arg_{iterator|begin|end}.  Likewise Module::g* -> Module::global_*.

This patch is contributed by Gabor Greif, thanks!

llvm-svn: 20597

llvm-svn: 20555

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

llvm-svn: 20554

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

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: 20382

llvm-svn: 20375

Changing 'op' here caused us to not enter the store into a map, causing
reemission of the code!!  In practice, a simple loop like this:

no_exit:                ; preds = %no_exit, %entry
        %indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ]            ; <uint> [#uses=3]
        %tmp.4 = getelementptr "complex long double"* %P, uint %indvar, uint 0          ; <double*> [#uses=1]
        store double 0.000000e+00, double* %tmp.4
        %indvar.next = add uint %indvar, 1              ; <uint> [#uses=2]
        %exitcond = seteq uint %indvar.next, %N         ; <bool> [#uses=1]
        br bool %exitcond, label %return, label %no_exit

was being code gen'd to:

.LBBtest_1:     # no_exit
        movl %edx, %esi
        shll $4, %esi
        movl $0, 4(%eax,%esi)
        movl $0, (%eax,%esi)
        incl %edx
        movl $0, (%eax,%esi)
        movl $0, 4(%eax,%esi)
        cmpl %ecx, %edx
        jne .LBBtest_1  # no_exit

Note that we are doing 4 32-bit stores instead of 2.  Now we generate:

.LBBtest_1:     # no_exit
        movl %edx, %esi
        incl %esi
        shll $4, %edx
        movl $0, (%eax,%edx)
        movl $0, 4(%eax,%edx)
        cmpl %ecx, %esi
        movl %esi, %edx
        jne .LBBtest_1  # no_exit

This is much happier, though it would be even better if the increment of ESI
was scheduled after the compare :-/

llvm-svn: 20265

llvm-svn: 20231

for 0.0 and -0.0.

llvm-svn: 20230

Don't sink argument loads into loops or other bad places.  This disables folding of argument loads with instructions that are not in the entry block.

llvm-svn: 20228

prints:

getelementptr (int* %A, int -1)

as: "(A) - 4" instead of "(A) + 18446744073709551612", which makes the
assembler much happier.

This fixes test/Regression/CodeGen/X86/2005-02-14-IllegalAssembler.ll,
and Benchmarks/Prolangs-C/cdecl with LLC on X86.

llvm-svn: 20183

targets.

llvm-svn: 20030

llvm-svn: 20026

llvm-svn: 19986

llvm-svn: 19969

llvm-svn: 19930

llvm-svn: 19924