Fix -Wdynamic-class-memaccess to skip invalid classes.

This warning sometimes will infinitely recurse on CXXRecordDecl's from
ill-formed recursive classes that have fields of themselves.  Skip processing
these classes to prevent this from happening.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27142

llvm-svn: 264991

[DebugInfo] Subprograms should belong to a CU.

Start fixing tests accordingly. There are still
about 35 failures before we can enable this check
in the IR verifier.

llvm-svn: 264990

Fix LWG issue 2469 - Use piecewise construction in map::operator[].

map's allocator may only be used to construct objects of 'value_type',
or in this case 'pair<const Key, Value>'. In order to respect this requirement
in operator[], which requires default constructing the 'mapped_type', we have
to use pair's piecewise constructor with '(tuple<Kep>, tuple<>)'.

Unfortunately we still need to provide a fallback implementation for C++03
since we don't have <tuple>. Even worse this fallback is the last remaining
user of '__hash_map_node_destructor' and '__construct_node_with_key'.

This patch also switches try_emplace over to __tree.__emplace_unique_key_args.

llvm-svn: 264989

[PowerPC] Load two floats directly instead of using one 64-bit integer load

When dealing with complex<float>, and similar structures with two
single-precision floating-point numbers, especially when such things are being
passed around by value, we'll sometimes end up loading both float values by
extracting them from one 64-bit integer load. It looks like this:

  t13: i64,ch = load<LD8[%ref.tmp]> t0, t6, undef:i64
      t16: i64 = srl t13, Constant:i32<32>
    t17: i32 = truncate t16
  t18: f32 = bitcast t17
    t19: i32 = truncate t13
  t20: f32 = bitcast t19

The problem, especially before the P8 where those bitcasts aren't legal (and
get expanded via the stack), is that it would have been better to use two
floating-point loads directly. Here we add a target-specific DAGCombine to do
just that. In short, we turn:

ld 3, 0(5)
stw 3, -8(1)
rldicl 3, 3, 32, 32
stw 3, -4(1)
lfs 3, -4(1)
lfs 0, -8(1)

into:

        lfs 3, 4(5)
        lfs 0, 0(5)

llvm-svn: 264988

[DarwinDriver] Increase the number of valid digits for ld64 version string.

Previously only 3 digits were valid. Increase it to 5.

Differential Revision: http://reviews.llvm.org/D18304

rdar://problem/24843016

llvm-svn: 264987

Teach __tree how to handle map's __value_type

This patch is fairly large and contains a number of changes. The changes all work towards
allowing __tree to properly handle __value_type esspecially when inserting into the __tree.
I chose not to break this change into smaller patches because it wouldn't be possible to
write meaningful standard-compliant tests for each patch.

It is very similar to r260513 "[libcxx] Teach __hash_table how to handle unordered_map's __hash_value_type".

Changes in <map>
 * Remove __value_type's constructors because it should never be constructed directly.

 * Make map::emplace and multimap::emplace forward to __tree and remove the old definitions

 * Remove "__construct_node" map and multimap member functions. Almost all of the construction is done within __tree.

 * Fix map's move constructor to access "__value_type.__nc" directly and pass this object to __tree::insert.

Changes in <__tree>
 * Add traits to detect, handle, and unwrap, map's "__value_type".

 * Convert methods taking "value_type" to take "__container_value_type" instead. Previously these methods caused
  unwanted implicit conversions from "std::pair<Key, Value>" to "__value_type<Key, Value>".

 * Delete __tree_node and __tree_node_base's constructors and assignment operators. The node types should never be constructed
   because the "__value_" member of __tree_node must be constructed directly by the allocator.

 * Make the __tree_node_destructor class and "__construct_node" methods unwrap "__node_value_type" into "__container_value_type" before invoking the allocator. The user's allocator can only be used to construct and destroy the container's value_type. Passing it map's "__value_type" was incorrect.

 * Cleanup the "__insert" and "__emplace" methods. Have __insert forward to an __emplace function wherever possible to reduce
   code duplication. __insert_unique(value_type const&) and __insert_unique(value_type&&) forward to __emplace_unique_key_args.
   These functions will not allocate a new node if the value is already in the tree.

 * Change the __find* functions to take the "key_type" directly instead of passing in "value_type" and unwrapping the key later.
   This change allows the find functions to be used without having to construct a "value_type" first. This allows for a number
   of optimizations.

 * Teach __move_assign and __assign_multi methods to unwrap map's __value_type.

llvm-svn: 264986

Update container_test_types.h and cleanup the related tests

llvm-svn: 264985

Fix case confusion.

The test case was defining and using a function 'notExported()', but
the FileCheck checks were checking for the name 'not_exported'. This
changes the test to use 'notExported' across the board. Also, the test
defined a function 'not_defined()', but doesn't have any checks related
to it. For consistency, this name is changed to 'notDefined'. A later
commit will add checks for 'notDefined'.

Patch by Warren Ristow!

llvm-svn: 264984

Revert "Remove useless unreachable.  Switch coverage already gives us this.  NFC"

This reverts commit r264945.

The commit only removed an unreachable in a method with a covered switch, but
GCC is likely to warn on this, and the coding standards recommend just leaving
in the unreachable.

llvm-svn: 264983

Remove unused variants of make_dynamic_error_code.  NFC.

make_dynamic_error_code was used to create a std::error_code with
a std::string message.  Now that we are migrating to llvm::Error,
there are no calls to these make_dynamic_error_code methods.

There is one single call to make_dynamic_error_code remaining, the one
inside GenericError::convertToErrorCode().  That method is only called
from File::doParse() which should be a temporary situation.  We need
to work out how to deal with File::parse() caching the error result from
doParse().  Caching errors isn't supported in the new scheme, and probably
isn't needed here, but we need to work that out.

Once thats done, dynamic error and all utilities around it can be deleted.

llvm-svn: 264982

Use Expected<T> instead of ErrorOr<T>in yaml reader.  NFC

llvm-svn: 264981

Add --help and --long-help options to 'command alias' such that one can now specify a help string for an alias as they are defining it

llvm-svn: 264980

Change library search methods to return Optional instead of ErrorOr.

These methods weren't really throwing errors.  The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file.  All of the callers
also ignored errors and just used the returned path if one was available.

Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.

llvm-svn: 264979

Fix a bunch more of -Wpessimizing-move issues.

Thanks to Rui for pointing out this warning was firing.

llvm-svn: 264978

Fix a bunch of -Wpessimizing-move issues.

Thanks to Rui for pointing out this warning was firing.

llvm-svn: 264977

Introduce a @llvm.experimental.guard intrinsic

Summary:
As discussed on llvm-dev[1].

This change adds the basic boilerplate code around having this intrinsic
in LLVM:

 - Changes in Intrinsics.td, and the IR Verifier
 - A lowering pass to lower @llvm.experimental.guard to normal
   control flow
 - Inliner support

[1]: http://lists.llvm.org/pipermail/llvm-dev/2016-February/095523.html

Reviewers: reames, atrick, chandlerc, rnk, JosephTremoulet, echristo

Subscribers: mcrosier, llvm-commits

Differential Revision: http://reviews.llvm.org/D18527

llvm-svn: 264976

[Sema] Fix PR27122: ICE with enable_if+ill-formed call.

In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the call to the function was valid. For example, in C:

int foo();
int a = foo(1);

Prior to this patch, we'd get an ICE if foo had an enable_if attribute,
because CheckEnableIf assumes that the number of arguments it gets
passed is valid for the function it's passed. Now, we check that the
number of args looks valid prior to checking enable_if conditions.

This fix was not done inside of CheckEnableIf because the problem
presently can only occur in one caller of CheckEnableIf (ActOnCallExpr).
Additionally, checking inside of CheckEnableIf would make us emit
multiple diagnostics for the same error (one "enable_if failed", one
"you gave this function the wrong number of arguments"), which seems
worse than just complaining about the latter.

llvm-svn: 264975

Convert a few macho reader/writer helpers to new error handling.  NFC.

These methods were responsible for some of the few remaining calls
to llvm::errorCodeToError.  Converting them makes us have more Error's
in the api and fewer error_code's.

llvm-svn: 264974

Convert readBinary to llvm::Error.  NFC

llvm-svn: 264973

Add some more triples after r264966

llvm-svn: 264972

[CrashReproducer] Add a module map callback for added headers

The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to collect
all headers needed in the crash reproducer. One of the reasons is that
the AST writer doesn't write symbolic link header paths in the pcm modules,
this makes the listeners on the reader only able to collect the real files.

Since the module maps could contain submodules that use headers which
are symbolic links, not collecting those forbid the reproducer scripts
to regen the modules.

For instance:

usr/include/module.map:
  ...
  module pthread {
    header "pthread.h"
    export *

    module impl {
      header "pthread_impl.h"
      export *
    }
  }
  ...

usr/include/pthread/pthread_impl.h
usr/include/pthread_impl.h -> pthread/pthread_impl.h

The AST dump for the module above:

  <SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h'
  <SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h'

Note that we don't have "usr/include/pthread_impl.h" which is requested
by the module.map in case we want to reconstruct the module in the
reproducer. The reason the original symbolic link path isn't used is
because the headers are kept by name and requested through the
FileManager, which unique files and returns the real path only.

To fix that, add a callback to be invoked everytime a header is added
while parsing module maps and hook that up to the module dependecy
collector. This callback is only registered when generating the
reproducer.

Differential Revision: http://reviews.llvm.org/D18585

rdar://problem/24499339

llvm-svn: 264971

[VFS] Handle empty entries in directory traversal

The VFS YAML files contain empty directory entries to describe that it's
returning from a subdirectory before describing new files in the parent.
In the future, we should properly sort and write YAML files avoiding
such empty dirs and mitigate the extra recurson cost. However, since
this is used by previous existing YAMLs, make the traversal work in
their presence.

rdar://problem/24499339

llvm-svn: 264970

[CUDA] Add -disable-llvm-passes to CodeGenCUDA/link-device-bitcode.cu.  NFC

We already have this flag in most of the file, but we need it everywhere
else, to disable the NVVMReflect pass, which we're explicitly checking
doesn't run here.  (Upcoming changes to llvm will cause it to be run.)

llvm-svn: 264969

Convert normalized file to atoms methods to new error handling.  NFC.

This converts almost all of the error handling in atom creation
to llvm::Error instead of std::error_code.

llvm-svn: 264968

Fix deduction of __atomic_load's parameter types.

Summary:
__atomic_load's allows it's first argument to be a pointer to a const type. However the second argument is an output parameter and must be a pointer to non-const.
This patch fixes the signature of __atomic_load generated by clang so that it respects the above requirements.

Reviewers: rsmith, majnemer

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D13420

llvm-svn: 264967

[X86] Enable call frame optimization ("mov to push") not only for optsize (PR26325)

The size savings are significant, and from what I can tell, both ICC and GCC do this.

Differential Revision: http://reviews.llvm.org/D18573

llvm-svn: 264966

[CUDA] Don't initialize the CUDA toolchain if we don't have any CUDA inputs.

Summary:
This prevents errors when you invoke clang with a flag that the NVPTX
toolchain doesn't support.  For example, on x86-64,

  clang -mthread-model single -x c++ /dev/null -o /dev/null

should output just one error about "invalid thread model 'single' in
'-mthread-model single' for this target"; x86-64 doesn't support
-mthread-model, but we shouldn't also instantiate a NVPTX target!

Reviewers: echristo

Subscribers: tra, sunfish, cfe-commits

Differential Revision: http://reviews.llvm.org/D18629

llvm-svn: 264965

[CUDA] Make unattributed constexpr functions implicitly host+device.

With this patch, by a constexpr function is implicitly host+device
unless:

 a) it's a variadic function (variadic functions are not allowed on the
    device side), or
 b) it's preceeded by a __device__ overload in a system header.

The restriction on overloading __host__ __device__ functions on the
basis of their CUDA attributes remains in place, but we use (b) to allow
us to define __device__ overloads for constexpr functions in cmath,
which would otherwise be __host__ __device__ and thus not overloadable.

You can disable this behavior with -fno-cuda-host-device-constexpr.

Reviewers: tra, rnk, rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D18380

llvm-svn: 264964

[CUDA] Add math forward declares to CUDA header wrapper.

Summary:
This is necessary for a future patch which will make all constexpr
functions implicitly host+device.  cmath may declare constexpr
functions, but these we do *not* want to be host+device.  The forward
declares added in this patch prevent this (because the rule will be,
constexpr functions become implicitly host+device unless they're
preceeded by a decl with __device__).

Reviewers: tra

Subscribers: cfe-commits, rnk, rsmith

Differential Revision: http://reviews.llvm.org/D18539

llvm-svn: 264963

Fix MachO test which is failing on a Windows bot.

This is breaking http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/31647/steps/test%20lld/logs/stdio.

The issue seems to be that it can't write to a file in /tmp, probably because that path doesn't
exist on Windows.  This was failing after I added EXPECT_FALSE(ec) in r264961 for the error
handling migration.

llvm-svn: 264962

Convert lld file writing to llvm::Error.  NFC.

This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.

llvm-svn: 264961

AMDGPU: Add frexp_mant + frexp_exp builtins

llvm-svn: 264960

CodeGen: Factor out code for tail call result compatibility check; NFC

llvm-svn: 264959

Avoid unnecessary #include; NFC

llvm-svn: 264958

Enhance the 'type X list' commands such that they actually alert the user if no formatters matching the constraints could be found

llvm-svn: 264957

[ELF][MIPS] Revert r264761 and add test case to demonstrate the problem

If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
  target is a preemptible symbol

Differential Revision: http://reviews.llvm.org/D18607

llvm-svn: 264956

Update copyright year to 2016.

llvm-svn: 264955

Update copyright year to 2016.

llvm-svn: 264954

Update copyright year to 2016.

llvm-svn: 264953

Update copyright year to 2016.

llvm-svn: 264952

Fix -Wpessimizing-move warnings.

llvm-svn: 264951

Update copyright year to 2016.

llvm-svn: 264950

Update copyright year to 2016.

llvm-svn: 264949

Update copyright year to 2016.

llvm-svn: 264948

Update copyright year to 2016.

llvm-svn: 264947

Update copyright year to 2016.

llvm-svn: 264946

Remove useless unreachable.  Switch coverage already gives us this.  NFC

llvm-svn: 264945

AMDGPU: Add frexp_exp intrinsic

llvm-svn: 264944

AMDGPU: Constant folding for frexp_mant

llvm-svn: 264943

Docs: keep copyright years up-to-date.

llvm-svn: 264942

Docs: keep copyright years up-to-date.

llvm-svn: 264941

Fix Clang crash with template type diffing.

Fixes https://llvm.org/bugs/show_bug.cgi?id=27129 which is crash involving type
aliases and template type diffing.  Template arguments for type aliases and
template arguments for the underlying desugared type may not have one-to-one
relations, which could mess us the attempt to get more information from the
desugared type.  For type aliases, ignore the iterator over the desugared type.

llvm-svn: 264940

Add -emit-llvm-only to the regression test for PR21547.

llvm-svn: 264939

[asan] Mark the initialization-bug.cc unsupported on OS X Yosemite and older

This test should fail on OS X Yosemite and older, and pass on OS X El Capitan
and newer as well as on other platforms.

llvm-svn: 264938

Canonicalize UnaryTransformType types when they don't have a known underlying type.

Fixes https://llvm.org/bugs/show_bug.cgi?id=26014

Reviewed by Richard Smith.

llvm-svn: 264937

Use existing PrintEscapedString in AssemblyWriter

r264884 introduced a helper to escape the backslashes in the source file
path, but I since discovered an existing mechanism to escape strings.

llvm-svn: 264936

Cloning: Reduce complexity of debug info cloning and fix correctness issue.

Commit r260791 contained an error in that it would introduce a cross-module
reference in the old module. It also introduced O(N^2) complexity in the
module cloner by requiring the entire module to be visited for each function.
Fix both of these problems by avoiding use of the CloneDebugInfoMetadata
function (which is only designed to do intra-module cloning) and cloning
function-attached metadata in the same way that we clone all other metadata.

Differential Revision: http://reviews.llvm.org/D18583

llvm-svn: 264935

Fix bug when KMP_USE_ADAPTIVE_LOCKS is 0

#endif was one line too low.  If KMP_USE_ADAPTIVE_LOCKS is 0,
then queuing locks would incorrectly use drdpa lock mechanism.
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=26649

llvm-svn: 264934

fix typos

llvm-svn: 264933

Silencing warnings from MSVC 2015 Update 2. Both of these changes silence "C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.

llvm-svn: 264932

AMDGPU: Remove separate r600 double data layout

This is identical to the other r600 datalayout string.

llvm-svn: 264931

[Clang][ARM] __va_list declaration is not saved in ASTContext causing compilation error or crash

Summary:
When the code is compiled for arm32 and the builtin `__va_list` declaration is created by `CreateAAPCSABIBuiltinVaListDecl`, the declaration is not saved in the `ASTContext` which may lead to a compilation error or crash.

Minimal reproducer I was able to find:
**header.h**
```
#include <stdarg.h>
typedef va_list va_list_1;
```

**test.cpp**
```
typedef __builtin_va_list va_list_2;
void foo(const char* format, ...) { va_list args; va_start( args, format ); }
```

Steps to reproduce:
```
clang -x c++-header --target=armv7l-linux-eabihf header.h
clang -c -include header.h --target=armv7l-linux-eabihf test.cpp
```

Compilation error:
```
error: non-const lvalue reference to type '__builtin_va_list'
      cannot bind to a value of unrelated type 'va_list' (aka '__builtin_va_list')
```

Compiling the same code as a C source leads to a crash:
```
clang --target=armv7l-linux-eabihf header.h
clang -c -x c -include header.h --target=armv7l-linux-eabihf test.cpp
```

Reviewers: logan, rsmith

Subscribers: cfe-commits, asl, aemerson, rengolin

Differential Revision: http://reviews.llvm.org/D18557

llvm-svn: 264930

Silencing warnings from MSVC 2015 Update 2. All of these changes silence "C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.

llvm-svn: 264929

LegalizeDAG: Don't replace vector store with integer if not legal

For the same reason as the corresponding load change.

Note that ExpandStore is completely broken for non-byte sized element
vector stores, but preserve the current broken behavior which has tests
for it. The behavior should be the same, but now introduces a new typed
store that is incorrectly split later rather than doing it directly.

llvm-svn: 264928

LegalizeDAG: Don't replace vector load with integer unless legal

On AMDGPU we want to be able to promote i64/f64 loads to v2i32.
If the access is unaligned, this would conclude that since i64 is legal,
it would convert it back to i64 and there is an endless legalization
loop.

Extract the logic for scalarizing the load into a new TargetLowering
function, where this can also replace the custom function AMDGPU
has for this.

llvm-svn: 264927

[IndVarSimplify] Don't insert after a catchswitch

Widening a PHI requires us to insert a trunc.
The logical place for this trunc is in the same BB as the PHI.
This is not possible if the BB is terminated by a catchswitch.

This fixes PR27133.

llvm-svn: 264926

[LTO] Add a test to ensure we treat externally available symbols correctly.

We already get it right, but there was no coverage for it.

llvm-svn: 264925

Convert file handle* methods to llvm::Error instead of std::error_code.  NFC.

This updates most of the file handling methods in the linking context and
resolver to use the new API.

llvm-svn: 264924

Add #include <functional> to PassManagerBuilder, now that it uses std::function. NFC

llvm-svn: 264923

[X86][AVX] Ensure EltsFromConsecutiveLoads tests the entire vector for consecutive loads/zeros

Fix for issue introduced D17297, where we were breaking early from the loop detecting consecutive loads which could leave us thinking a consecutive load with zeros was possible.

llvm-svn: 264922

Change loadFileList to llvm::Error.  NFC

llvm-svn: 264921

[Sema] s/UseUsingDeclRules/UseMemberUsingDeclRules/

Summary:
IsOverload has a param named UseUsingDeclRules.  But as far as I can
tell, it should be called UseMemberUsingDeclRules.  That is, it only
applies to "using" declarations inside classes or structs.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D18538

llvm-svn: 264920

[NVPTX] Make NVVMReflect a function pass.

Summary:
Currently it's a module pass.  Make it a function pass so that we can
move it to PassManagerBuilder's EP_EarlyAsPossible extension point,
which only accepts function passes.

Reviewers: rnk

Subscribers: tra, llvm-commits, jholewinski

Differential Revision: http://reviews.llvm.org/D18615

llvm-svn: 264919

[PassManager] Make PassManagerBuilder::addExtension take an std::function, rather than a function pointer.

Summary:
This gives callers flexibility to pass lambdas with captures, which lets
callers avoid the C-style void*-ptr closure style.  (Currently, callers
in clang store state in the PassManagerBuilderBase arg.)

No functional change, and the new API is backwards-compatible.

Reviewers: chandlerc

Subscribers: joker.eph, cfe-commits

Differential Revision: http://reviews.llvm.org/D18613

llvm-svn: 264918

Convert lld Pass::runOnFile to llvm::Error from std::error_code.  NFC.

Pretty mechanical change here.  Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>

llvm-svn: 264917

test: Remove a test for a transform that hasn't existed in 5 years.

The TailDup transform was removed in r138841 in 2011, along with most
of the tests for it. This test, however, was missed. Probably because
it had already been XFAIL'd for 3 years at that point (since r52243!)
and continued to fail when the opt flag for -tailduplicate stopped
being valid.

llvm-svn: 264916

Attempt to fix test failure on Windows.

Windows seems to complain that the file cannot be removed because
it is still in use. We don't have to remove the file but instead
just overwrite it, so do that.

llvm-svn: 264915

Fixed a problem where a dSYM wasn't properly found because it had the wrong name

<rdar://problem/25447765>

llvm-svn: 264914

[modules] Write out identifiers if the ID is local, too.

In some cases a slot for an identifier is requested but it gets written to
another module, causing an assertion.

At the point when we start serializing Rtypes, we have no imported IdentifierID
for float_round_style. We start serializing stuff and allocate an ID for it.
Then, during the serialization process, we pull in the identifier info for it
from TSchemaHelper. Finally, WriteIdentifierTable decides that the identifier
has not changed since it was deserialized, so doesn't emit it.

Fixes https://llvm.org/bugs/show_bug.cgi?id=27041

Discussed on IRC with Richard Smith. Agreed on post commit review if needed.

llvm-svn: 264913

Fix the detection of the shell feature and disable some tests when its not present

llvm-svn: 264912

Remove unused fwd decl for LLVM IR stuff that lives in LTO now

llvm-svn: 264911

Change getReferenceInfo/getPairReferenceInfo to use new Error handling.  NFC.

Adds a GenericError class to lld/Core which can carry a string.  This is
analygous to the dynamic_error we currently use in lld/Core.

Use this GenericError instead of make_dynamic_error_code.  Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have.  This will go away once
all the APIs are converted.

llvm-svn: 264910

When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset

There was a mixing and matching of this and it wasn't done consistently.

Major changes include:

The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:

DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)

It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.

The function:

lldb::user_id_t DIERef::GetUID() const;

Now becomes

lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;

Again, we need the DWARF file to encode it correctly.

This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:

1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.

There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.

If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.

<rdar://problem/25200976>

llvm-svn: 264909

[modules] Add a regression test for PR21547.

llvm-svn: 264908

Add a copy constructor to StringMap

There is code under review that requires StringMap to have a copy constructor,
and this makes StringMap more consistent with our other containers (like
DenseMap) that have copy constructors.

Differential Revision: http://reviews.llvm.org/D18506

llvm-svn: 264906

Split Writer::assignAddresses. NFC.

llvm-svn: 264905

[LoopVectorize] Don't vectorize loops when everything will be scalarized

This change prevents the loop vectorizer from vectorizing when all of the vector
types it generates will be scalarized. I've run into this problem on the PPC's QPX
vector ISA, which only holds floating-point vector types. The loop vectorizer
will, however, happily vectorize loops with purely integer computation. Here's
an example:

  LV: The Smallest and Widest types: 32 / 32 bits.
  LV: The Widest register is: 256 bits.
  LV: Found an estimated cost of 0 for VF 1 For instruction:   %indvars.iv25 = phi i64 [ 0, %entry ], [ %indvars.iv.next26, %for.body ]
  LV: Found an estimated cost of 0 for VF 1 For instruction:   %arrayidx = getelementptr inbounds [1600 x i32], [1600 x i32]* %a, i64 0, i64 %indvars.iv25
  LV: Found an estimated cost of 0 for VF 1 For instruction:   %2 = trunc i64 %indvars.iv25 to i32
  LV: Found an estimated cost of 1 for VF 1 For instruction:   store i32 %2, i32* %arrayidx, align 4
  LV: Found an estimated cost of 1 for VF 1 For instruction:   %indvars.iv.next26 = add nuw nsw i64 %indvars.iv25, 1
  LV: Found an estimated cost of 1 for VF 1 For instruction:   %exitcond27 = icmp eq i64 %indvars.iv.next26, 1600
  LV: Found an estimated cost of 0 for VF 1 For instruction:   br i1 %exitcond27, label %for.cond.cleanup, label %for.body
  LV: Scalar loop costs: 3.
  LV: Found an estimated cost of 0 for VF 2 For instruction:   %indvars.iv25 = phi i64 [ 0, %entry ], [ %indvars.iv.next26, %for.body ]
  LV: Found an estimated cost of 0 for VF 2 For instruction:   %arrayidx = getelementptr inbounds [1600 x i32], [1600 x i32]* %a, i64 0, i64 %indvars.iv25
  LV: Found an estimated cost of 0 for VF 2 For instruction:   %2 = trunc i64 %indvars.iv25 to i32
  LV: Found an estimated cost of 2 for VF 2 For instruction:   store i32 %2, i32* %arrayidx, align 4
  LV: Found an estimated cost of 1 for VF 2 For instruction:   %indvars.iv.next26 = add nuw nsw i64 %indvars.iv25, 1
  LV: Found an estimated cost of 1 for VF 2 For instruction:   %exitcond27 = icmp eq i64 %indvars.iv.next26, 1600
  LV: Found an estimated cost of 0 for VF 2 For instruction:   br i1 %exitcond27, label %for.cond.cleanup, label %for.body
  LV: Vector loop of width 2 costs: 2.
  LV: Found an estimated cost of 0 for VF 4 For instruction:   %indvars.iv25 = phi i64 [ 0, %entry ], [ %indvars.iv.next26, %for.body ]
  LV: Found an estimated cost of 0 for VF 4 For instruction:   %arrayidx = getelementptr inbounds [1600 x i32], [1600 x i32]* %a, i64 0, i64 %indvars.iv25
  LV: Found an estimated cost of 0 for VF 4 For instruction:   %2 = trunc i64 %indvars.iv25 to i32
  LV: Found an estimated cost of 4 for VF 4 For instruction:   store i32 %2, i32* %arrayidx, align 4
  LV: Found an estimated cost of 1 for VF 4 For instruction:   %indvars.iv.next26 = add nuw nsw i64 %indvars.iv25, 1
  LV: Found an estimated cost of 1 for VF 4 For instruction:   %exitcond27 = icmp eq i64 %indvars.iv.next26, 1600
  LV: Found an estimated cost of 0 for VF 4 For instruction:   br i1 %exitcond27, label %for.cond.cleanup, label %for.body
  LV: Vector loop of width 4 costs: 1.
  ...
  LV: Selecting VF: 8.
  LV: The target has 32 registers
  LV(REG): Calculating max register usage:
  LV(REG): At #0 Interval # 0
  LV(REG): At #1 Interval # 1
  LV(REG): At #2 Interval # 2
  LV(REG): At #4 Interval # 1
  LV(REG): At #5 Interval # 1
  LV(REG): VF = 8

The problem is that the cost model here is not wrong, exactly. Since all of
these operations are scalarized, their cost (aside from the uniform ones) are
indeed VF*(scalar cost), just as the model suggests. In fact, the larger the VF
picked, the lower the relative overhead from the loop itself (and the
induction-variable update and check), and so in a sense, picking the largest VF
here is the right thing to do.

The problem is that vectorizing like this, where all of the vectors will be
scalarized in the backend, isn't really vectorizing, but rather interleaving.
By itself, this would be okay, but then the vectorizer itself also interleaves,
and that's where the problem manifests itself. There's aren't actually enough
scalar registers to support the normal interleave factor multiplied by a factor
of VF (8 in this example). In other words, the problem with this is that our
register-pressure heuristic does not account for scalarization.

While we might want to improve our register-pressure heuristic, I don't think
this is the right motivating case for that work. Here we have a more-basic
problem: The job of the vectorizer is to vectorize things (interleaving aside),
and if the IR it generates won't generate any actual vector code, then
something is wrong. Thus, if every type looks like it will be scalarized (i.e.
will be split into VF or more parts), then don't consider that VF.

This is not a problem specific to PPC/QPX, however. The problem comes up under
SSE on x86 too, and as such, this change fixes PR26837 too. I've added Sanjay's
reduced test case from PR26837 to this commit.

Differential Revision: http://reviews.llvm.org/D18537

llvm-svn: 264904

[lld] [ELF/AArch64] Add aarch64 TLS IE to LE relax for local symbol test

This patch add a TLS relax optimization test when transforming
Initial-Exec to Local-Exec for local symbols (which can not be preempted).

llvm-svn: 264903

[PGO] PGOFuncName in LTO optimizations

PGOFuncNames are used as the key to retrieve the Function definition from the
MD5 stored in the profile. For internal linkage function, we prefix the source
file name to the PGOFuncNames. LTO's internalization privatizes many global linkage
symbols. This happens after value profile annotation, but those internal
linkage functions should not have a source prefix. To differentiate compiler
generated internal symbols from original ones, PGOFuncName meta data are
created and attached to the original internal symbols in the value profile
annotation step. If a symbol does not have the meta data, its original linkage
must be non-internal.

Also add a new map that maps PGOFuncName's MD5 value to the function definition.

Differential Revision: http://reviews.llvm.org/D17895

llvm-svn: 264902

[cmake] Get the MSVC version by running cl rather than relying on MSVC_VERSION

MSVC_VERSION comes from the _MSC_VER macro, which won't correspond to
the STL version if the host compiler is clang-cl.

llvm-svn: 264901

[cmake] Instead of testing char16_t for MSVC compat, directly ask cl.exe its version

Credit to Aaron Ballman for thinking of this.

llvm-svn: 264886

Revert 264782 and 264789

These caused LNT failures due to new assertions when running with
-polly-position=before-vectorizer -polly-process-unprofitable for:

FAIL: clamscan.compile_time
FAIL: cjpeg.compile_time
FAIL: consumer-jpeg.compile_time
FAIL: shapes.compile_time
FAIL: clamscan.execution_time
FAIL: cjpeg.execution_time
FAIL: consumer-jpeg.execution_time
FAIL: shapes.execution_time

The failures have been introduced by r264782, but r264789 had to be reverted
as it depended on the earlier patch.

llvm-svn: 264885

Restore "[ThinLTO] Serialize the Module SourceFileName to/from LLVM assembly"

This restores commit 264869, with a fix for windows bots to properly
escape '\' in the path when serializing out. Added test.

llvm-svn: 264884

Fix header name.

llvm-svn: 264883

[AArch64] Fix warnings pointed out by Hal.

llvm-svn: 264882

[cmake] Add -fms-compatibility-version=19 when clang-cl gives errors about char16_t

What we are really trying to do here is to figure out if we are using
the 2015 STL. Unfortunately, so far as I know the MSVC STL does not
define a version macro that we can check directly. Instead I wrote a
check to see if char16_t works.

llvm-svn: 264881

[cmake] Allow EH usage with clang-cl

llvm-svn: 264880

[PGO] Use ArrayRef in annotateValueSite()

Using ArrayRef in annotateValueSite's parameter instead of using an array
and it's size.

Differential Revision: http://reviews.llvm.org/D18568

llvm-svn: 264879

Include line number in error message for linker scripts.

This patch is based on http://reviews.llvm.org/D18545 written
by George Rimar.

llvm-svn: 264878

AMDGPU/SI: Improve MachineSchedModel definition

This patch contains a few improvements to the model, including:

- Using a single resource with a defined buffers size for each memory unit.
- Setting the IssueWidth correctly.
- Fixing latency values for memory instructions.

shader-db stats:

16429 shaders in 3231 tests
Totals:
SGPRS: 318232 -> 312328 (-1.86 %)
VGPRS: 208996 -> 209346 (0.17 %)
Code Size: 7147044 -> 7166440 (0.27 %) bytes
LDS: 83 -> 83 (0.00 %) blocks
Scratch: 1862656 -> 1459200 (-21.66 %) bytes per wave
Max Waves: 49182 -> 49243 (0.12 %)
Wait states: 0 -> 0 (0.00 %)A

Differential Revision: http://reviews.llvm.org/D18453

llvm-svn: 264877