This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

DebugInfo: Tag units as having been indexed in GNU pubnames by using a DW_AT_GNU_pubnames of DW_FORM_flag(_present) rather than sec_offsets to the pubnames/types sections

This is consistent with GDB ToT and reduces the number of relocations in
(type and compile) units, substantially reducing relocations and debug
size in fission + type units builds.

llvm-svn: 203082

llvm-svn: 203081

llvm-svn: 203080

Remove 2 dead 'break' statements.  The 'break' usage in this switch is inconsistent, making this hard to see.

llvm-svn: 203079

llvm-svn: 203078

llvm-svn: 203077

llvm-svn: 203076

In addition, for all functions, use the name from the llvm::Function to
identify the function in the profile data. Compute that "function name",
including the file name for local functions, once when assigning the PGO
counters and store it in the CodeGenPGO class.

Move the code to add InlineHint and Cold attributes out of StartFunction(),
because the "function name" string isn't available at that point.

llvm-svn: 203075

For C++ functions, we will continue to use the mangled name to identify
functions in the PGO profile data, but this name is confusing for things like
Objective-C methods. For functions with local linkage, we're also going to
include the file name to help distinguish those functions, so this changes to
use more generic variable names.

No functional changes.

llvm-svn: 203074

Move the PGO.assignRegionCounters() call out of StartFunction, because that
function is called from many places where it does not make sense to do PGO
instrumentation (e.g., compiler-generated helper functions). Change several
functions to take a StringRef argument for the unique name associated with
a function, so that the name can be set differently for things like Objective-C
methods and block literals.

llvm-svn: 203073

I hit this while debugging another issue where my sources were in an
inconsistent state, so I don't have a testcase. Regardless, this check is
simpler and more direct than checking if the option is enabled.

llvm-svn: 203072

selfhost.

The 'Core.h' C-API header is part of the IR LLVM library. (One might
even argue it should be called IR.h, but that's a separate point.) We
can't include it into a Support header without violating the layering,
and in a way that breaks modules. MemoryBuffer's opaque C type was being
defined in the Core.h C-API header despite being in the Support library,
and thus we ended up with this weird issue.

It turns out that there were other constructs from the Support library
in the Core.h header. This patch lifts all of them into Support.h and
then includes that into Core.h.

The only possible fallout is if someone was including Support.h and
relying on Core.h to be visible for their own uses. Considering the
narrow interface actually provided by the C-API for the Support library,
this seems a very, very unlikely mistake.

llvm-svn: 203071

Instead, define explicit specializations for the basic types listed in
the SGI documentation. This solves two problems:

 1) Helps avoid silent ODR violations caused by the absence of a
    user-supplied __gnu_cxx::hash specialization in cases where a std::hash
    specialization exists (e.g. for std::string).

 2) __gnu_cxx::hash semantics are slightly different to those of
    std::hash (for example, the former may dereference a pointer argument)
    so it is inappropriate for __gnu_cxx::hash to receive std::hash
    specializations by default.

Differential Revision: http://llvm-reviews.chandlerc.com/D2747

llvm-svn: 203070

implementation already lived.

After this commit, the only IR-library headers in include/llvm/* are
ones related to the legacy pass infrastructure that I'm planning to
leave there until the new one is farther along.

The only other headers at the top level are linking and initialization
aids that aren't really libraries but just headers.

llvm-svn: 203069

Temporarily disable the JIT loading detector till we figure out why it crashes when lldb follows through exec's...

llvm-svn: 203068

subdirectory in LLVM r203065.

llvm-svn: 203067

llvm-svn: 203066

consistent with every other sub-library header in LLVM.

llvm-svn: 203065

obviously coupled to the IR.

llvm-svn: 203064

submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.

llvm-svn: 203063

llvm-svn: 203062

llvm-svn: 203061

It ought to be possible to make this truly random access if anyone cares enough.

llvm-svn: 203060

This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.

Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.

In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.

In summary, I have no idea why weak linkage was being used :-(

To quote John McCall, "Let’s try without it and see" :-)

llvm-svn: 203059

Chandler in review.

llvm-svn: 203058

DebugInfo: Shrink pubnames/pubtypes in the presence of type units by only emitting pub sections for compile units

llvm-svn: 203057

llvm-svn: 203056

llvm-svn: 203055

The global base register cannot be r0 because it might end up as the first
argument to addi or addis. Fixes PR18316.

I don't have a small stable test case.

llvm-svn: 203054

The iterator is a little complex because we don't want to expose the implementation
details (TrackingVH) of the operand vector to clients.

llvm-svn: 203053

llvm-svn: 203052

Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.

llvm-svn: 203051

a white background is difficult to read.  Also include a chart showing which
colors are used by which elements in the AST dump.

llvm-svn: 203050

in LLVM r203046.

llvm-svn: 203049

in LLVM r203046.

llvm-svn: 203047

already lives.

llvm-svn: 203046

Like on other targets, we need to zero_extend/truncate i1 args before copying
them to GPRs.

llvm-svn: 203045

pointed to by the attribute, rather than the form as a first
step to determining how to hash the values. No functional change
intended.

llvm-svn: 203044

the property assignment is an lvalue for an incomplete type.
// rdar://15118128. Reviewed offline by John McCall.

llvm-svn: 203043