This reopens PR99114, but that one at least can be avoided with an #include.
PR9130 cannot.

llvm-svn: 124780

llvm-svn: 124779

llvm-svn: 124778

This is the Makefile version only; the cmake implementation is coming soon.

llvm-svn: 124777

links.

llvm-svn: 124776

This is the cmake equivalent for r124769.

llvm-svn: 124775

llvm-svn: 124774

Reversing the operands allows us to fold, but doesn't force us to. Also, at
this point the DAG is still being optimized, so the check for hasOneUse is not
very precise.

llvm-svn: 124773

the atomic writes option, since the intent is that this option be set for an
entire build, which may have any number of compiler instances writing to the
same output file.

llvm-svn: 124772

llvm-svn: 124771

llvm-svn: 124770

llvm-svn: 124769

is not defined in the current translation unit. Doing so lead to compile errors
such as PR9114.

Instead, when CodeGen is building the vtable, don't try to emit a definition
for functions that aren't marked used in the current translation unit.
Fixes PR9114.

llvm-svn: 124768

llvm-svn: 124767

(regardless if the interrupt was sent), and false of not.

llvm-svn: 124766

The greedy register allocator revealed some problems with the value mapping in
SplitKit. We would sometimes start mapping values before all defs were known,
and that could change a value from a simple 1-1 mapping to a multi-def mapping
that requires ssa update.

The new approach collects all defs and register assignments first without
filling in any live intervals. Only when finish() is called, do we compute
liveness and mapped values. At this time we know with certainty which values map
to multiple values in a split range.

This also has the advantage that we can compute live ranges based on the
remaining uses after rematerializing at split points.

The current implementation has many opportunities for compile time optimization.

llvm-svn: 124765

llvm-svn: 124764

llvm-svn: 124763

substitutions in order to achieve file mappings.

Modify CommandObjectTarget.cpp to properly set the status of the return object to make
scripting like this:

    self.runCmd("target image-search-paths add %s %s" % (os.getcwd(), new_dir))

works.

llvm-svn: 124762

llvm-svn: 124761

redundant searches in the string. No functionality change.

llvm-svn: 124760

llvm-svn: 124759

Based on user feedback, swap -Wuninitialized diagnostics to have the warning refer to the bad use, and the note to the variable declaration.

llvm-svn: 124758

llvm-svn: 124757

llvm-svn: 124756

llvm-svn: 124755

on that name. Canonicalization eliminates silliness such as "." and
"foo/.." that breaks the uniquing of files in the presence of virtual
files or files whose inode numbers have changed during
parsing/re-parsing. c-index-test isn't able to create this crazy
situation, so I've resorted to testing outside of the Clang
tree. Fixes <rdar://problem/8928220>.

Note that this hackery will go away once we have a real virtual file
system on which we can layer FileManager; the virtual-files hack is
showing cracks.

llvm-svn: 124754

llvm-svn: 124753

llvm-svn: 124752

CC_PRINT_OPTIONS and can be used to get some out-of-band information on header
usage from a build.

llvm-svn: 124751

information to a file.

llvm-svn: 124750

ones outside the predefines buffer (which is what -H does).

llvm-svn: 124749

llvm-svn: 124748

overflow (nsw flag), which was disabled because it breaks 254.gap.  I have
informed the GAP authors of the mistake in their code, and arranged for the
testsuite to use -fwrapv when compiling this benchmark.

llvm-svn: 124746

but has non-empty data fields, such as array of zero length,
remains zero.
// rdar://8945175

llvm-svn: 124741

savings of 25% sounds impressive, except that this amounted to only
about 360k in our standard "large" completion result set (40,000
results). Since code completion is performance-sensitive, the 4%
slowdown due to uniquing outweighs the 360k benefit. 

llvm-svn: 124737

llvm-svn: 124736

llvm-svn: 124735

The algorithm for identifying which operand is invalid will now always point to
some operand and not the mnemonic sometimes.  The change is now that ErrorInfo
is the index of the highest operand that does not match for any of the matching
mnemonics records.  And no longer the ~0U value when the mnemonic matches and
not every record with a matching mnemonic has the same mismatching operand
index.

llvm-svn: 124734

more test cases

Fixed minor bug in the breakpoint id range translation code.

llvm-svn: 124729