llvm-svn: 99011

--- Reverse-merging r98889 into '.':
U    lib/Target/ARM/ARMInstrNEON.td
U    lib/Target/ARM/ARMISelLowering.h
U    lib/Target/ARM/ARMInstrInfo.td
U    lib/Target/ARM/ARMInstrVFP.td
U    lib/Target/ARM/ARMISelLowering.cpp
U    lib/Target/ARM/ARMInstrFormats.td

llvm-svn: 99010

instead of as a single element list with VoidTy.

llvm-svn: 99009

ranges as part of the ASTContext. This code is not and was never used,
but contributes ~250k to the size of the Cocoa.h precompiled
header.

llvm-svn: 99007

instantiations when we have the corresponding macro definition and by
removing macro definition information from our table when the macro is
undefined. 

llvm-svn: 99004

ApplyTypeConstraint) and make it handle multiple result nodes.

llvm-svn: 99003

record (which includes all macro instantiations and definitions). As
with all lay deserialization, this introduces a new external source
(here, an external preprocessing record source) that loads all of the
preprocessed entities prior to iterating over the entities.

The preprocessing record is an optional part of the precompiled header
that is disabled by default (enabled with
-detailed-preprocessing-record). When the preprocessor given to the
PCH writer has a preprocessing record, that record is written into the
PCH file. When the PCH reader is given a PCH file that contains a
preprocessing record, it will be lazily loaded (which, effectively,
implicitly adds -detailed-preprocessing-record). This is the first
case where we have sections of the precompiled header that are
added/removed based on a compilation flag, which is
unfortunate. However, this data consumes ~550k in the PCH file for
Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
this detailed preprocessing information, so it's too expensive to turn
on by default. In the future, we should investigate a better encoding
of this information.

llvm-svn: 99002

use-before-def errors in SCEVExpander-produced code in sqlite3 when debug
info with optimization is enabled, though the testcases for this are
dependent on use-list order.

llvm-svn: 99001

that they are dead.

llvm-svn: 99000

to maintain a list of types (one for each result of
the node) instead of a single type.  There are liberal
hacks added to emulate the old behavior in various
situations, but they can start disolving now.

llvm-svn: 98999

projects rely upon llvm-gcc, the LLVM test suite, and poolalloc.  This ensures
that the aforementioned projects have their object trees created first so that
other projects can find their object trees when they themselves are configured.

llvm-svn: 98998

llvm-svn: 98994

(related to radar 7538989).

llvm-svn: 98993

llvm-svn: 98990

llvm-svn: 98989

llvm-svn: 98988

is valid, but not useful, when variable  identified by !1 is optimized away by the optimizer.

llvm-svn: 98986

llvm-svn: 98985

llvm-svn: 98982

llvm-svn: 98981

override prefix and only the r/m16 forms should have had that.  Also for variant
one, the AT&T syntax, added suffixes to all forms.  Also added the missing
64-bit form for 'CRC32 r64, r/m8'.  Plus added test cases for all forms and
tweaked one test case to add the needed suffixes.

llvm-svn: 98980

llvm-svn: 98979

actual action.
 - This is easier to use, and more reliable for timing the thing this was
   actually meant to be useful for.

llvm-svn: 98978

disabled for several months (since svn r88806) and no one noticed.  My fix
for pr6543 yesterday reenabled it, but broke the ARM port's code for using
TBB/TBH.  Rather than adding a target hook to disable merging for Thumb2 only,
I'm just taking this out.  It is not common to have identical jump tables,
the code we used to merge them was O(N^2), and it only helps code size, not
performance.

llvm-svn: 98977

mostly during conditional expressions.

llvm-svn: 98975

 - This is "extraordinarily" Darwin 'as' compatible. See the litany of FIXMEs littered about for more information.
 - There are a few cases which seem to clearly be 'as' bugs which I have left unsupported, and there is one cases where we diverge but should fix if it blocks diffing .o files (Darwin 'as' ends up widening a jump unnecessarily).
 - 403.gcc build, runs, and diffs equivalently to the 'as' built version now (using llvm-mc). However, it builds so slowly that I wouldn't recommend trying it quite yet. :)

llvm-svn: 98974

llvm-svn: 98973

MC/X86: Rename alternate spellings of {ADD64,CMP64} and mark as "code gen only" so they don't get selected by the asm matcher.

llvm-svn: 98972

"scanning from here" one.

llvm-svn: 98971

object pointer types.
Fixes radar 7634850.

llvm-svn: 98970

Python 2.4 always hits this bug: http://bugs.python.org/issue1731717
when running check-lit on multi-core systems.
Setting numThreads to 1 makes it slower, but at least the results reported are
correct.

llvm-svn: 98969

we don't blow the smallvector as often.  No functionality change.

llvm-svn: 98968

room for it.  This is in preparation for another patch which is adding NEON
subformats to facilitate disassembly.

llvm-svn: 98967

eliminating the extra PopulatePreprocessingRecord object. This will
become useful once we start writing the preprocessing record to
precompiled headers.

llvm-svn: 98966

tie its creation to a CC1 flag -detailed-preprocessing-record.

llvm-svn: 98963

llvm-svn: 98962

llvm-svn: 98961

information, to address recent gdb failures.

llvm-svn: 98959

back out r98957, it broke http://smooshlab.apple.com:8010/builders/clang-x86_64-darwin10-fnt/builds/703 in the nightly test suite

llvm-svn: 98958

This time I did a self-hosted bootstrap on Linux x86-64,
with no problems. Let's see how darwin 64-bit self-hosting
goes. At the first sign of failure I'll back this out.

Maybe the valgrind bots give me a hint of what may be wrong
(it at all).

llvm-svn: 98957