llvm-svn: 143190

llvm-svn: 143189

it fixes the dragonegg self-host (it looks like gcc is miscompiled).
Original commit messages:
Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.

Delete #if 0 code accidentally left in.

llvm-svn: 143188

tools that read the debug info in the .o files by making the DIE sizes more
consistent.

llvm-svn: 143186

Fixes rdar://10359193 Indvar LinearFunctionTestReplace assertion

llvm-svn: 143183

llvm-svn: 143179

on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.

Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.

Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.

Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.

This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.

llvm-svn: 143177

Previously, if invoked from a CMake build directory, 'llvm-config
--cppflags' and friends would only print a -I flag for the build
directory's header search path, because it would assume that it was
already installed, not recognising its parent directory as being the
build directory.  Teach llvm-config about CMake build directories
so that it prints a -I for both the source and build directory's
search paths.

llvm-svn: 143171

Just treat it as if the constituent D registers where specified.

rdar://10348896

llvm-svn: 143167

llvm-svn: 143164

llvm-svn: 143163

llvm-svn: 143162

Previously, we were only setting the alignment bits on over-aligned
loads and stores.

llvm-svn: 143160

llvm-svn: 143159

llvm-svn: 143158

llvm-svn: 143153

Revert r143149, stubbing out symbolic disassembly support.  The symbolic disassembly support is too MC-engrained to be useful in llvm-objdump.

llvm-svn: 143152

If we're searching for a symbol reference to pretty-print a scattered relocation address, and we don't find a symbol table entry, try section begin addresses as well.

llvm-svn: 143151

llvm-svn: 143149

 - This will require you to manually reconfigure the projects/sample project (by running projects/config/sample/config.status --recheck) if you haven't updated/built since the 1st part of this commit went in.

llvm-svn: 143148

llvm-svn: 143145

llvm-svn: 143143

llvm-svn: 143142

 - Also, cleanup site.exp files in example tests.

llvm-svn: 143141

Fix pretty printing of i386 local sect diff relocations, TLV relocations, and x86_64 TLV relocations in MachO.

llvm-svn: 143140

llvm-svn: 143135

comments at top of TypeBasedAliasAnalysis.cpp).

llvm-svn: 143134

using BinaryOperator (which only works for instructions) when it should have
been a cast to OverflowingBinaryOperator (which also works for constants).
While there, correct a few other dubious looking uses of BinaryOperator.
Thanks to Chad Rosier for the testcase.  Original commit message:
My super-optimizer noticed that we weren't folding this expression to
true: (x *nsw x) sgt 0, where x = (y | 1).  This occurs in 464.h264ref.

llvm-svn: 143125

llvm-svn: 143120

llvm-svn: 143117

llvm-svn: 143116

llvm-svn: 143113

not depend on In32BitMode.  Use the sysexitq mnemonic for the version with the
REX.W prefix and only allow it only In64BitMode.  rdar://9738584

llvm-svn: 143112

rdar://10348844

llvm-svn: 143110

llvm-svn: 143109

rdar://10348584

llvm-svn: 143108

llvm-svn: 143107

This trades one 64 bit div for one 64 bit mul and some arithmetic.

llvm-svn: 143106

behind a compile failure on 483.xalancbmk.

llvm-svn: 143102

llvm-svn: 143101