llvm-svn: 46513

llvm-svn: 46510

compiler warnings.

llvm-svn: 46509

llvm-svn: 46508

llvm-svn: 46506

avoid turning -0.0 + 0.0 -> -0.0 which is incorrect.

llvm-svn: 46499

to get the alignment of global variables, rather than
using hand-made versions.

llvm-svn: 46495

the handling of eliminating stores to byval arguments.

llvm-svn: 46494

llvm-svn: 46488

llvm-svn: 46486

llvm-svn: 46485

These loops are not yet handled.

Fix PR 1912.

llvm-svn: 46484

only two addressing mode nodes, SPUaform and SPUindirect (vice the
three previous ones, SPUaform, SPUdform and SPUxform). This improves
code somewhat because we now avoid using reg+reg addressing when
it can be avoided. It also simplifies the address selection logic,
which was the main point for doing this.

Also, for various global variables that would be loaded using SPU's
A-form addressing, prefer D-form offs[reg] addressing, keeping the
base in a register if the variable is used more than once.

llvm-svn: 46483

llvm-svn: 46458

llvm-svn: 46455

the function label isn't associated with something it shouldn't be.

llvm-svn: 46449

llvm-svn: 46433

llvm-svn: 46431

llvm-svn: 46429

way or the other.  Rewriting the code itself prevents subsequent analysis
passes from making contradictory conclusions about the code that could 
cause an infeasible path to be made feasible.

llvm-svn: 46427

llvm-svn: 46424

llvm-svn: 46422

llvm-svn: 46420

llvm-svn: 46417

longer allowed to write through byval arguments.

llvm-svn: 46416

registers if used by a bitconvert or using a bitconvert.  This allows us to
avoid constant pool loads and use cheaper integer instructions when the
values come from or end up in integer regs anyway.  For example, we now 
compile CodeGen/X86/fp-in-intregs.ll to:

_test1:
	movl	$2147483648, %eax
	xorl	4(%esp), %eax
	ret
_test2:
	movl	$1065353216, %eax
	orl	4(%esp), %eax
	andl	$3212836864, %eax
	ret

Instead of:
_test1:
	movss	4(%esp), %xmm0
	xorps	LCPI2_0, %xmm0
	movd	%xmm0, %eax
	ret
_test2:
	movss	4(%esp), %xmm0
	andps	LCPI3_0, %xmm0
	movss	LCPI3_1, %xmm1
	andps	LCPI3_2, %xmm1
	orps	%xmm0, %xmm1
	movd	%xmm1, %eax
	ret

bitconverts can happen due to various calling conventions that require
fp values to passed in integer regs in some cases, e.g. when returning
a complex.

llvm-svn: 46414

llvm-svn: 46413

llvm-svn: 46411

This fixes PR1769.

llvm-svn: 46408

For long double constants, print an approximation of their value to the .s file to make it easier to read.

llvm-svn: 46407

llvm-svn: 46406

llvm-svn: 46405

now that the dag combiner does it.

llvm-svn: 46404

from the stack.  This allows us to compile stack-align.ll to:

_test:
	movsd	LCPI1_0, %xmm0
	movapd	%xmm0, %xmm1
***	andpd	4(%esp), %xmm1
	andpd	_G, %xmm0
	addsd	%xmm1, %xmm0
	movl	20(%esp), %eax
	movsd	%xmm0, (%eax)
	ret

instead of:

_test:
	movsd	LCPI1_0, %xmm0
**	movsd	4(%esp), %xmm1
**	andpd	%xmm0, %xmm1
	andpd	_G, %xmm0
	addsd	%xmm1, %xmm0
	movl	20(%esp), %eax
	movsd	%xmm0, (%eax)
	ret

llvm-svn: 46401

nop. Emit the nop directly for PPC.

llvm-svn: 46398

a "nop" instruction so that we don't have the function's label associated
with something that it's not supposed to be associated with.

llvm-svn: 46394

when inlining a readonly function.

llvm-svn: 46393

void bork() {
  int *address = 0;
  *address = 0;
}

It's compiled into LLVM code that looks like this:

define void @bork() noreturn nounwind  {
entry:
        unreachable
}

This is bad on some platforms (like PPC) because it will generate the label for
the function but no body. The label could end up being associated with some
non-code related stuff, like a section. This places a "trap" instruction if the
SimplifyCFG pass removed all code from the function leaving only one
"unreachable" instruction.

llvm-svn: 46387

delete a node even if it was not dead in some cases.  Instead, just add it to
the worklist.  Also, make sure to use the CombineTo methods, as it was doing
things that were unsafe: the top level combine loop could touch dangling memory.

This fixes CodeGen/Generic/2008-01-25-dag-combine-mul.ll

llvm-svn: 46384

don't bother making x&-1 only to simplify it in dag combine.  This commonly occurs expanding i64 ops.

llvm-svn: 46383