Added a linearscan register allocation optimization. When the register allocator spill an interval with multiple uses in the same basic block, it creates a different virtual register for each of the reloads. e.g.

	%reg1498<def> = MOV32rm %reg1024, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg1024, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg1024, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

=>

        %reg1498<def> = MOV32rm %reg2036, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg2037, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg2038, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

From linearscan's point of view, each of reg2036, 2037, and 2038 are separate registers, each is "killed" after a single use. The reloaded register is available and it's often clobbered right away. e.g. In thise case reg1498 is allocated EAX while reg2036 is allocated RAX. This means we end up with multiple reloads from the same stack slot in the same basic block.

Now linearscan recognize there are other reloads from same SS in the same BB. So it'll "downgrade" RAX (and its aliases) after reg2036 is allocated until the next reload (reg2037) is done. This greatly increase the likihood reloads from SS are reused.

This speeds up sha1 from OpenSSL by 5.8%. It is also an across the board win for SPEC2000 and 2006.

llvm-svn: 69585

raw_ostreams. Requires LLVM r69583.

llvm-svn: 69584

llvm-svn: 69583

 - No functionality change.

llvm-svn: 69582

@synthesized ivars for superclasses.
 - <rdar://problem/6806371> [clang] Mark code without miscompiled
   @synthesized properties

llvm-svn: 69581

llvm-svn: 69580

Drop uses of GetFirstInvarInRecord, instead we lookup the ivars we
know are in the record.
 - This is somewhat less efficient, but I need to detangle this code
   first...

llvm-svn: 69579

llvm-svn: 69578

llvm-svn: 69577

llvm-svn: 69576

null string / identifier.

llvm-svn: 69575

pointer type, make sure that the pointer size is a valid sequential index type.

llvm-svn: 69574

llvm-svn: 69573

Also, added assertion that the field matches what would be looked up.

llvm-svn: 69572

remove special case hack for -Werror-implicit-function-declaration

llvm-svn: 69571

get FunctionDecl with more general utility method.

llvm-svn: 69570

llvm-svn: 69569

llvm-svn: 69568

subsequently crashed).

llvm-svn: 69567

Adapted from patch by Tim Northover.

llvm-svn: 69566

methods of SVal.

llvm-svn: 69565

useful for macro-heavy codebases that tend to trigger this warning a 
lot.

Note that a make clean is required to get the option working; the 
dependencies for DiagnosticGroups.inc appear to be broken.

llvm-svn: 69564

llvm-svn: 69563

llvm-svn: 69562

 - No functionality change.

llvm-svn: 69561

will let us test for multiple different warning modes in the same
file in regression tests.

This implements rdar://2362963, a 10-year old feature request :)

llvm-svn: 69560

Warnings.cpp.  Warnings.cpp now doesn't need to #include
tblgen produced output directly.

llvm-svn: 69559

mode, just ignore them as usual.

llvm-svn: 69558

llvm-svn: 69557

support it.  I don't know what evaluation method we use for complex
arithmetic, so I don't know whether/if we should warn about use of
CX_LIMITED_RANGE.

This concludes my planned hacking on STDC pragmas, flame away :)

llvm-svn: 69556

llvm-svn: 69555

llvm-svn: 69554

llvm-svn: 69553

Let me know if I messed up for some target.  Note that for Windows, we 
should be able to support it (MSVC supports "__declspec(thread)"), but 
I'm pretty sure LLVM doesn't know how to generate the correct code.

llvm-svn: 69552

llvm-svn: 69551

llvm-svn: 69550

llvm-svn: 69549

llvm-svn: 69548

llvm-svn: 69547

llvm-svn: 69546