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

llvm-svn: 103430

function calls, not just recognized intrinsics.

llvm-svn: 103428

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

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

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

llvm-svn: 103419

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

Based on a patch by Javier Martinez.

llvm-svn: 103391

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

patch by Nathan Jeffords!

llvm-svn: 103346

ungracefully.

llvm-svn: 103334

stuff.

llvm-svn: 103333

LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.

This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.

Also, add a few asserts to diagnose this kind of situation.

llvm-svn: 103328

llvm-svn: 103327

llvm-svn: 103325

llvm-svn: 103318

and not the real problem itself, by dropping debug info for i128 values.
rdar://7958162.

llvm-svn: 103310

wider than 64 bits.

llvm-svn: 103309

llvm-svn: 103305

llvm-svn: 103304

llvm-svn: 103303

external and the item to be relocated should not have the address of the
symbol added in.

llvm-svn: 103302

llvm-svn: 103300

getConstantFP to accept the two supported long double
target types.  This was not the original intent, but
there are other places that assume this works and it's
easy enough to do.

llvm-svn: 103299

llvm-svn: 103295

whether the extract instructions are available.

rdar://7956878

llvm-svn: 103277

llvm-svn: 103276