llvm-svn: 140161

No functionality change. The hook makes it explicit which patterns
require "special" handling. i.e. it self-documents tblgen
deficiencies. I plan to add verification in ExpandISelPseudos and
Thumb2SizeReduce to catch any missing hasPostISelHooks. Otherwise it's
too fragile.

llvm-svn: 140160

from unfriendly (== not at all modularized) directories. This is
temporary, and it only affects module construction until I'll figured
out how to deal with system headers.

llvm-svn: 140159

llvm-svn: 140158

llvm-svn: 140157

llvm-svn: 140156

llvm-svn: 140155

llvm-svn: 140154

llvm-svn: 140153

llvm-svn: 140152

GCOVLines is always accessed through a StringMap where the key is FileName.

llvm-svn: 140151

llvm-svn: 140150

llvm-svn: 140149

llvm-svn: 140147

llvm-svn: 140146

There is no need to write a local utility routine to find subprogram info if the utility routine is already available in DebugInfo.

llvm-svn: 140145

change __builtin_va_list to from a structure to int[4] (same alignment
and size, but with a simpler representation). Patch by David Meyer!

llvm-svn: 140144

On Windows x64, 128-bit arguments are not passed by reg but by indirect. eg.

maxpd:
        vmovapd (%rcx), %xmm0
        vmaxpd  (%rdx), %xmm0, %xmm0

FIXME: I don't care YMM on x64 for now.
llvm-svn: 140143

Per John's review comments for r140068.

llvm-svn: 140142

llvm-svn: 140140

presence of an implicit move assignment operator.  I think the implicit
copy assignment operator case was also wrong, but just in a "displaying
the wrong diagnostic" way.

llvm-svn: 140139

of false positive warnings that depend on noreturn destructors pruning
the CFGs, but only in C++0x mode!

This was really surprising as the debugger quickly reveals that the
attributes are parsed correctly (and using the same code) in both modes.
The warning fires in the same way in both modes. But between parsing and
building the destructor declaration with the noreturn attribute and the
warning, it magically disappears. The key? The 'noexcept' appears!

When we were rebuilding the destructor type with the computed implicit
noexcept we completely dropped the old type on the floor. This almost
makes sense (as the arguments and return type to a destructor aren't
exactly unpredictable), but lost any function type attributes as well.
The fix is simple, we build the new type off of the old one rather than
starting fresh.

Testing this is a bit awkward. I've done it by running the
noreturn-sensitive tests in both modes, which previous failed and now
passes, but if anyone has ideas about how to more specifically and
thoroughly test that the extended info on a destructor is preserved when
adding noexcept, I'm all ears.

llvm-svn: 140138

include/llvm/Config/llvm-config.h.in: Add the entry LLVM_PATH_XDOT_PY, for consistency against llvm-config.h.cmake.

llvm-svn: 140137

llvm-svn: 140136

llvm-svn: 140135

Modified ARMISelLowering::AdjustInstrPostInstrSelection to handle the
full gamut of CPSR defs/uses including instructins whose "optional"
cc_out operand is not really optional. This allowed removal of the
hasPostISelHook to simplify the .td files and make the implementation
more robust.
Fixes rdar://10137436: sqlite3 miscompile

llvm-svn: 140134

llvm-svn: 140133

llvm-svn: 140132

[analyzer] Refactor PathDiagnosticLocation: Pre-compute Range and Location with gen methods on object creation instead of computing on demand. This would allow to remove dependency on the other members which help with construction and might not even be valid at later stages (to be removed later on).

llvm-svn: 140131

llvm-svn: 140130

llvm-svn: 140129

This basically involved removing references to llvm.eh.exception,
llvm.eh.selector, and llvm.eh.resume and replacing them with references to the
landingpad and resume instructions.

llvm-svn: 140128

llvm-svn: 140127

llvm-svn: 140126

llvm-svn: 140125

llvm-svn: 140124

llvm-svn: 140123

llvm-svn: 140122

llvm-svn: 140121

llvm-svn: 140120