feels a kinship to machine stacks that grow down.  Now we get
stuff like this:

Stack dump:
0.	Program arguments: clang clang_crash_Iw2Osj.mi 
1.	/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:624:1: parsing function body '_mm_cvtpi16_ps'
2.	/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:624:1: in compound statement ('{}')
Abort

llvm-svn: 66145

llvm-svn: 66144

llvm-svn: 66143

This invalidates the stubs in the resolver map when they are no longer referenced,
and should the JIT memory manager ever pick up a deallocateStub interface, the
JIT could reclaim the memory for unused stubs as well.

llvm-svn: 66141

llvm-svn: 66140

Fix how livein live intervals are handled. Previously it could end at MBB start. Sorry, no small test case possible.

llvm-svn: 66129

codegen.  I convinced myself it was OK to skip all
pointer bitcasts here too.

llvm-svn: 66122

llvm-svn: 66119

llvm-svn: 66115

had 2 uses instead of 1.

llvm-svn: 66112

llvm-svn: 66083

that get printed when a program crashes.  This is the first step of many.

llvm-svn: 66076

was causing llvm-gcc to fail to build.  I've
verified it bootstraps now; good enough for me.

llvm-svn: 66073

arbitrary functions to be run when a crash happens.  Delete 
RemoveDirectoryOnSignal as it is dead and has never had clients.

Change PrintStackTraceOnErrorSignal to be implemented in terms of
AddSignalHandler.

I updated the Win32 versions of these APIs, but can't test them.
If there are any problems, I'd be happy to fix them as well.

llvm-svn: 66072

llvm-svn: 66065

immediately obvious.

llvm-svn: 66062

llvm-svn: 66058

llvm-svn: 66057

of MachineInstr def operands must be subtracted out. This bug
was uncovered by the recent x86 EFLAGS optimization. Before
that, the only instructions that ever needed unfolding were
things like CMP32rm, where NumDefs is zero.

llvm-svn: 66056

llvm-svn: 66055

llvm-svn: 66054

onto element accesses.

llvm-svn: 66053

  on failure to resolve it.
Do not abort on failure to resolve an external symbol when using dlsym stubs,
  since the symbol may not be in the JIT's address space.  Just use 0.
Allow dlsym stubs to differentiate between GlobalVars and Functions.

llvm-svn: 66050

It is an error to call APInt::zext with a size that is equal to the value's
current size, so use zextOrTrunc instead.

llvm-svn: 66039

Add a restore folder, which shaves a dozen or so machineinstrs off oggenc.  Update a testcase to check this.

llvm-svn: 66029

llvm-svn: 66024

llvm-svn: 66021

llvm-svn: 66008

result from add, sub, inc, and dec instructions in simple cases.

llvm-svn: 66004

llvm-svn: 66001

llvm-svn: 66000

per Chris' suggestion.  Slightly faster.

llvm-svn: 65999

Fix PR3701. 1. X86 target renamed eflags register to flags. This matches what llvm-gcc generates so codegen knows flags register is being clobbered by inline asm. 2. BURR scheduler should also check if inline asm nodes can clobber "live" physical registers. Previously it was only checking target nodes with implicit defs.

llvm-svn: 65996

If a global constant is dead then global's debug info should not prevent the optimizer in deleting the global. And while deleting global, delete global's debug info also.

llvm-svn: 65994

when counting work; it was only off by 1.

llvm-svn: 65993

so it changed it into a 31 via the TLO.ShrinkDemandedConstant() call. Then it
would go through the DAG combiner again. This time it had a value of 31, which
was turned into a -1 by TLI.SimplifyDemandedBits(). This would ping pong
forever.

Teach the TLO.ShrinkDemandedConstant() call not to lower a value if the demanded
value is an XOR of all ones.

llvm-svn: 65985

caused them to be considered trivially dead.  Fix this.

llvm-svn: 65979

feed into llvm.dbg.declare nodes, as well as
the debug directives themselves.

llvm-svn: 65976

llvm-svn: 65971

use, check also for the case where it has two uses,
the other being a llvm.dbg.declare.  This is needed so
debug info doesn't affect codegen.

llvm-svn: 65970