instead of a Constant*, which is what the clients of it really want.

llvm-svn: 66364

llvm-svn: 66363

llvm-svn: 66362

parent between MemCpyInst and MemMoveInst, simplify some code to
use it.

llvm-svn: 66361

llvm-svn: 66360

llvm-svn: 66359

For 2009-03-07-FPConstSelect.ll we now produce:

_f:
	xorl	%eax, %eax
	testl	%edi, %edi
	movl	$4, %ecx
	cmovne	%rax, %rcx
	leaq	LCPI1_0(%rip), %rax
	movss	(%rcx,%rax), %xmm0
	ret

previously we produced:

_f:
	subl	$4, %esp
	cmpl	$0, 8(%esp)
	movss	LCPI1_0, %xmm0
	je	LBB1_2	## entry
LBB1_1:	## entry
	movss	LCPI1_1, %xmm0
LBB1_2:	## entry
	movss	%xmm0, (%esp)
	flds	(%esp)
	addl	$4, %esp
	ret

on PPC the code also improves to:

_f:
	cntlzw r2, r3
	srwi r2, r2, 5
	li r3, lo16(LCPI1_0)
	slwi r2, r2, 2
	addis r3, r3, ha16(LCPI1_0)
	lfsx f1, r3, r2
	blr 

from:

_f:
	li r2, lo16(LCPI1_1)
	cmplwi cr0, r3, 0
	addis r2, r2, ha16(LCPI1_1)
	beq cr0, LBB1_2	; entry
LBB1_1:	; entry
	li r2, lo16(LCPI1_0)
	addis r2, r2, ha16(LCPI1_0)
LBB1_2:	; entry
	lfs f1, 0(r2)
	blr 

This also improves the existing pic-cpool case from:

foo:
	subl	$12, %esp
	call	.Lllvm$1.$piclabel
.Lllvm$1.$piclabel:
	popl	%eax
	addl	$_GLOBAL_OFFSET_TABLE_ + [.-.Lllvm$1.$piclabel], %eax
	cmpl	$0, 16(%esp)
	movsd	.LCPI1_0@GOTOFF(%eax), %xmm0
	je	.LBB1_2	# entry
.LBB1_1:	# entry
	movsd	.LCPI1_1@GOTOFF(%eax), %xmm0
.LBB1_2:	# entry
	movsd	%xmm0, (%esp)
	fldl	(%esp)
	addl	$12, %esp
	ret

to:

foo:
	call	.Lllvm$1.$piclabel
.Lllvm$1.$piclabel:
	popl	%eax
	addl	$_GLOBAL_OFFSET_TABLE_ + [.-.Lllvm$1.$piclabel], %eax
	xorl	%ecx, %ecx
	cmpl	$0, 4(%esp)
	movl	$8, %edx
	cmovne	%ecx, %edx
	fldl	.LCPI1_0@GOTOFF(%eax,%edx)
	ret

This triggers a few dozen times in spec FP 2000.

llvm-svn: 66358

llvm-svn: 66357

"boolify" pointers, generating really awful code because getting the pointer
value requires a load itself.  Before:

_foo:
	movb	$1, _X.b
	ret
_get:
	xorl	%ecx, %ecx
	movb	_X.b, %al
	testb	%al, %al
	movl	$_Y, %eax
	cmove	%ecx, %eax
	ret

With the xform disabled:

_foo:
	movl	$_Y, _X
	ret
_get:
	movl	_X, %eax
	ret

llvm-svn: 66351

and extern_weak_odr.  These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global.  In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time.   This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function.  If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body.  The
code generators on the other hand map weak and weak_odr linkage
to the same thing.

llvm-svn: 66339

llvm-svn: 66336

llvm-svn: 66333

signal handlers to prevent reentrance on unrelated things (a sigabort
where the handle bus errors) also, clear the signal mask so that the
signal doesn't infinitely reissue.  This fixes rdar://6654827 -
Crash causes clang to loop

llvm-svn: 66330

1. When the JIT is asked to remove a function, updating it's
   mapping to 0, we invalidate any function stubs used only 
   by that function.  Now, also invalidate the JIT's mapping
   from the GV the stub pointed to, to the address of the GV.

2. When dlsym stubs for cross-process JIT are enabled, do not
   abort just because a named function cannot be found in the
   JIT's process.

3. Fix various assumptions about when it is ok to use the lazy
   resolver when non-lazy JITing is enabled.

llvm-svn: 66324

the same say the "test" instruction does in overflow cases,
so eliminating the test is only safe when those bits aren't
needed, as is the case for COND_E and COND_NE, or if it
can be proven that no overflow will occur. For now, just
restrict the optimization to COND_E and COND_NE and don't
do any overflow analysis.

llvm-svn: 66318

table.
 - No functionality change.

llvm-svn: 66289

an optimization.

llvm-svn: 66288

llvm-svn: 66279

Lennart Augustsson!

llvm-svn: 66272

to find a tiny mouse hole to squeeze through, it struck
me that globals without a name can be considered internal
since they can't be referenced from outside the current
module.  This patch makes GlobalOpt give them internal
linkage.  Also done for aliases even though they always
have names, since in my opinion anonymous aliases should
be allowed for consistency with global variables and
functions.  So if that happens one day, this code is ready!

llvm-svn: 66267

llvm-svn: 66264

llvm-svn: 66262

get nice and happy stack traces when we crash in an optimizer or codegen.  For
example, an abort put in UnswitchLoops now looks like this:

Stack dump:
0.	Program arguments: clang pr3399.c -S -O3 
1.	<eof> parser at end of file
2.	per-module optimization passes
3.	Running pass 'CallGraph Pass Manager' on module 'pr3399.c'.
4.	Running pass 'Loop Pass Manager' on function '@foo'
5.	Running pass 'Unswitch loops' on basic block '%for.inc'
Abort

llvm-svn: 66260

IntrNoMem.

llvm-svn: 66256

llvm-svn: 66255

llvm-svn: 66254

llvm-svn: 66252

their main routines.  This makes the tools print their argc/argv
commands if they crash.

llvm-svn: 66248

llvm-svn: 66245

llvm-svn: 66244

with multiple chain operands. This can occur when the scheduler
has added chain operands to a node that already has a chain
operand, in order to handle physical register dependencies.

This fixes an llvm-gcc bootstrap failure on x86-64 introduced
in r66058.

llvm-svn: 66240

This is needed so debug info doesn't change codegen.

llvm-svn: 66235

Delete this default branch, because we're going to generate our own.

llvm-svn: 66234

llvm-svn: 66233

We are still not out of woods yet.

llvm-svn: 66232

llvm-svn: 66227

debug intrinsics correctly.

llvm-svn: 66225

llvm-svn: 66224

llvm-svn: 66223

INC64_32r and INC64_16r, because these instructions are encoded
differently on x86-64. This fixes JIT regressions on x86-64 in
kimwitu++ and others.

llvm-svn: 66207