llvm-svn: 103455

instructions as well.  Added support for checking
this to the llvm-mc tester as well.

llvm-svn: 103454

llvm-svn: 103453

string of features for that target. However LTO was using that string to pass
into the "create target machine" stuff. That stuff needed the feature string to
be in a particular form. In particular, it needed the CPU specified first and
then the attributes. If there isn't a CPU specified, it required it to be blank
-- e.g., ",+altivec". Yuck.

Modify the getDefaultSubtargetFeatures method to be a non-static member
function. For all attributes for a specific subtarget, it will add them in like
normal. It will also take a CPU string so that it can satisfy this horrible
syntax.

llvm-svn: 103451

llvm-svn: 103450

llvm-svn: 103449

scattered relocation entry with a .weak_definition.

llvm-svn: 103443

llvm-svn: 103442

llvm-svn: 103441

This means now 'llvm-ld a.bc b.bc' will preserve debug info appropriately.

llvm-svn: 103439

MC/Mach-O: Explicitly track atoms, as represented by their defining symbol, for each fragment (not yet used).

llvm-svn: 103438

llvm-svn: 103437

llvm-svn: 103436

llvm-svn: 103435

llvm-svn: 103434

llvm-svn: 103432

llvm-svn: 103431

llvm-svn: 103430

function calls, not just recognized intrinsics.

llvm-svn: 103428

llvm-svn: 103427

Fix PR6875:

This includes a patch by Roman Divacky to fix the initial crash.

Move the actual addition of passes from *PassManager::add to
*PassManager::addImpl.  That way, when adding printer passes we won't
recurse infinitely.

Finally, check to make sure that we are actually adding a FunctionPass
to a FunctionPassManager before doing a print before or after it.
Immutable passes are strange in this way because they aren't
FunctionPasses yet they can be and are added to the FunctionPassManager.

llvm-svn: 103425

llvm-svn: 103424

Add new configure option, --disable-timestamps, intended to turn off anything which would mess up binary/object comparisons. Currently:
 - Disables 'Built on ...' in 'foo --version'.
 - Disables timestamps from being embedded into .dir files.

llvm-svn: 103423

llvm-svn: 103422

llvm-svn: 103420

Be careful with operand promotion. For a binary operation, the source operands may be the same. PR7018. rdar://7939869.

llvm-svn: 103419

llvm-svn: 103415

llvm-svn: 103411

llvm-svn: 103410

SSAUpdater for the value from the first def may see uses of undefined values,
because the later defs will not have been updated yet.

llvm-svn: 103407

llvm-svn: 103399

Remove sending duplicate of the --gcc-tool-args parameters to gcc.

llvm-svn: 103397

Based on a patch by Javier Martinez.

llvm-svn: 103391

llvm-svn: 103383

changed dllexport code to use EmitBytes instead of EmitRawText, and changed the export option to use /EXPORT: instead of -export: on the windows platform

llvm-svn: 103377

llvm-svn: 103373

llvm-svn: 103372

when it detects undefined behavior.  llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial".  For example, we now compile:

void foo() { *(int*)0 = 42; }

into:

_foo:
	pushl	%ebp
	movl	%esp, %ebp
	ud2

Some may even claim that this is a security hole, though that seems dubious
to me.  This addresses rdar://7958343 - Optimizing away null dereference 
potentially allows arbitrary code execution

llvm-svn: 103356

with a vector input and output into a shuffle vector.  This sort of 
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.

This fixes rdar://7896024

llvm-svn: 103354

llvm-svn: 103347