llvm-svn: 100693

llvm-svn: 100692

llvm-svn: 100691

ARMDecoderEmitter.cpp, with FIXME comment.

llvm-svn: 100690

emitting diagnostics after it has produced that many errors.  Give this a
default value of 20 which produces plenty of errors for people to fix before
recompiling but not so many that their entire console scrolls away when the
compiler gets confused.  The experience looks like this:

$ clang foo.c
<tons of crap>
foo.c:102:3: error: unknown type name 'somethingbad'
  somethingbad x;
  ^
fatal error: too many errors emitted, stopping now
36 warnings and 20 errors generated.

llvm-svn: 100689

those who don't build all targets.

llvm-svn: 100688

llvm-svn: 100687

isn't any extra work to perform. Also, don't check for unused
parameters when the warnings will be suppressed anyway. Improves
performance of -fsyntax-only on 403.gcc's combine.c by ~2.5%. 
<rdar://problem/7836787>

llvm-svn: 100686

a simple mapping of register names to IDs to
identify register tokens.

llvm-svn: 100685

Right now the limit is 0 (aka disabled)

llvm-svn: 100684

llvm-svn: 100682

DBG_VALUE does not generate code.

llvm-svn: 100681

llvm-svn: 100677

or similar side-effects.

llvm-svn: 100676

of errors and warnings.  This allows us to emit something like this:

2 warnings and 1 error generated.

instead of:

3 diagnostics generated.

This also stops counting 'notes' because they are just follow-on information
about the previous diag, not a diagnostic in themselves.

llvm-svn: 100675

llvm-svn: 100674

It is not ready for public yet.

llvm-svn: 100673

llvm-svn: 100672

llvm-svn: 100671

llvm-svn: 100670

llvm-svn: 100669

llvm-svn: 100668

llvm-svn: 100667

llvm-svn: 100666

llvm-svn: 100665

llvm-svn: 100664

llvm-svn: 100663

llvm-svn: 100662

llvm-svn: 100661

llvm-svn: 100660

llvm-svn: 100659

llvm-svn: 100658

llvm-svn: 100657

llvm-svn: 100656

llvm-svn: 100655

llvm-svn: 100654

llvm-svn: 100653

VHADD differs from VHSUB at least on A9 - the former reads both operands in the second cycle, while the latter reads second operand in first cycle. Introduce new itin classes to catch this behavior. Whether this is true for A8 as well is WIP.

llvm-svn: 100652

llvm-svn: 100651

Define new itin classes for ARM <-> VFP reg moves to distinguish from NEON ops. Define proper scheduling itinerary for them on A9. A8 TRM does not specify latency for them at all :(

llvm-svn: 100650