[PGO] Avoid instrumenting constants at value sites

Value profiling should not profile constants and/or constant
expressions when they appear as callees in call instructions.
Constant expressions form when a direct callee has bitcasts or
inttoptr(ptrtint (callee)) nests surrounding it. Value profiling
should avoid instrumenting such cases. Mostly NFC.

llvm-svn: 265037

Change eliminateCallFramePseudoInstr() to return an iterator

This will become necessary in a subsequent change to make this method
merge adjacent stack adjustments, i.e. it might erase the previous
and/or next instruction.

It also greatly simplifies the calls to this function from Prolog-
EpilogInserter. Previously, that had a bunch of logic to resume iteration
after the call; now it just continues with the returned iterator.

Note that this changes the behaviour of PEI a little. Previously,
it attempted to re-visit the new instruction created by
eliminateCallFramePseudoInstr(). That code was added in r36625,
but I can't see any reason for it: the new instructions will obviously
not be pseudo instructions, they will not have FrameIndex operands,
and we have already accounted for the stack adjustment.

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

llvm-svn: 265036

Fix the comment for the function added in r264998.

llvm-svn: 265035

[lit][googletest] Handle upstream gtest output

Summary:
Upstream googletest prints "Running main() from gtest_main.cc" to stdout prior
to running tests. LLVM removed that print statement in r61540. If a user were
to use lit to run tests that use upstream googletest, however, lit
reports "Running main()" as an invalid test name.

To avoid such a failure, add an extra conditional to `formats/googletest.py`.
Also add tests to demonstrate the modified behavior.

Reviewers: abdulras, ddunbar

Subscribers: ddunbar, llvm-commits, kastiglione

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

llvm-svn: 265034

[clang-tidy] Add a new checker to detect missing comma in initializer list.

Summary:
This checker is able to detect missing comma in
an array of string literals.

```
  const char* A[] = {
    "abc",
    "def"   // missing comma (no compiler warnings)
    "ghi",
  };
```

The ratio of false-positive is reduced by restricting the
size of the array considered and the ratio of missing
comma.

To validate the quantity of false positive, the checker
was tried over LLVM and chromium code and detected these
cases:

[[ http://reviews.llvm.org/D18454 | http://reviews.llvm.org/D18454 ]]
[[https://codereview.chromium.org/1807753002/ | https://codereview.chromium.org/1807753002/]]
[[https://codereview.chromium.org/1826193002/ | https://codereview.chromium.org/1826193002/]]
[[https://codereview.chromium.org/1805713002/ | https://codereview.chromium.org/1805713002/]]

Reviewers: alexfh

Subscribers: LegalizeAdulthood, szdominik, xazax.hun, cfe-commits

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

llvm-svn: 265033

[lanai] isBrImm should accept any non-constant immediate.

isBrImm should accept any non-constant immediate. Previously it was only accepting LanaiMCExpr ones which was wrong.

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

llvm-svn: 265032

[PPC] basic support for Power 9 direct move instructions

http://reviews.llvm.org/D18097

Initial support does not include any patterns to generate this instructions

llvm-svn: 265031

[PGO] use emplace_back. NFC.

Use emplace_back instead of push_back for simplicity.

llvm-svn: 265030

[x86] use SSE/AVX ops for non-zero memsets (PR27100)

Move the memset check down to the CPU-with-slow-SSE-unaligned-memops case: this allows fast
targets to take advantage of SSE/AVX instructions and prevents slow targets from stepping
into a codegen sinkhole while trying to splat a byte into an XMM reg.

Follow-on bugs exposed by the current codegen are:
https://llvm.org/bugs/show_bug.cgi?id=27141
https://llvm.org/bugs/show_bug.cgi?id=27143

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

llvm-svn: 265029

[AMDGPU] enable few disassembler tests that were mistakenly marked as FIXME.

llvm-svn: 265028

More checks in win32-seh-nested-finally.ll after comment on r264966

llvm-svn: 265027

[PowerPC] Attempt to fix fast-isel-i64offset.ll failure

The test case added in r265023 is failing on ninja-x64-msvc-RA-centos6.
Update the test to make less specific assumptions on code generation.

llvm-svn: 265026

Minor code cleanup /NFC

llvm-svn: 265025

Don't use potentially invalidated iterator

If the lhs is evaluated before the rhs, FuncletI's operator-> can trigger the

  assert(isHandleInSync() && "invalid iterator access!");

at include/llvm/ADT/DenseMap.h:1061.  (Happens e.g. when compiled with GCC 6.)

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

llvm-svn: 265024

[PowerPC] Correctly compute 64-bit offsets in fast isel

PPCSimplifyAddress contains this code:

  IntegerType *OffsetTy = ((VT == MVT::i32) ? Type::getInt32Ty(*Context)
                                            : Type::getInt64Ty(*Context));

to determine the type to be used for an index register, if one needs
to be created.  However, the "VT" here is the type of the data being
loaded or stored, *not* the type of an address.  This means that if
a data element of type i32 is accessed using an index that does not
not fit into 32 bits, a wrong address is computed here.

Note that PPCFastISel is only ever used on 64-bit currently, so the type
of an address is actually *always* MVT::i64.  Other parts of the code,
even in this same PPCSimplifyAddress routine, already rely on that fact.
Thus, this patch changes the code to simply unconditionally use
Type::getInt64Ty(*Context) as OffsetTy.

llvm-svn: 265023

[PowerPC] Basic support for P9 atomic loads and stores

This patch corresponds to review:
http://reviews.llvm.org/D18032

This patch provides asm implementation for the following instructions:
lwat, ldat, stwat, stdat, ldmx, mcrxrx

llvm-svn: 265022

[AArch64] Handle missing store pair opportunity

Summary:
This change will handle missing store pair opportunity where the first store
instruction stores zero followed by the non-zero store. For example, this change
will convert :

  str wzr, [x8]
  str w1, [x8, #4]
into:
  stp wzr, w1, [x8]

Reviewers: jmolloy, t.p.northover, mcrosier

Subscribers: flyingforyou, aemerson, rengolin, mcrosier, llvm-commits

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

llvm-svn: 265021

[PowerPC] Remove incorrect use of COPY_TO_REGCLASS in fast isel

The fast isel pass currently emits a COPY_TO_REGCLASS node to convert
from a F4RC to a F8RC register class during conversion of a
floating-point number to integer. There is actually no support in the
common code instruction printers to emit COPY_TO_REGCLASS nodes, so the
PowerPC back-end has special code there to simply ignore
COPY_TO_REGCLASS.

This is correct *if and only if* the source and destination registers of
COPY_TO_REGCLASS are the same (except for the different register class).
But nothing guarantees this to be the case, and if the register
allocator does end up allocating source and destination to different
registers after all, the back-end simply generates incorrect code. I've
included a test case that shows such incorrect code generation.

However, it seems that COPY_TO_REGCLASS is actually not intended to be
used at the MI layer at all. It is used during SelectionDAG, but always
lowered to a plain COPY before emitting MI. Other back-end's fast isel
passes never emit COPY_TO_REGCLASS at all. I suspect it is simply wrong
for the PowerPC back-end to emit it here.

This patch changes the PowerPC back-end to directly emit COPY instead of
COPY_TO_REGCLASS and removes the special handling in the instruction
printers.

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

llvm-svn: 265020

[mips] Range check simm16

Summary:
There are too many instructions to exhaustively test so addiu and lwc2 are
used as representative examples.

It should be noted that many memory instructions that should have simm16
range checking do not because it is also necessary to support the macro
of the same name which accepts simm32. The range checks for these occur in
the macro expansion.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265019

[mips] Range check simm11 and mem_simm11.

Summary:
ldc2/sdc2 now emit slightly worse diagnostics for MIPS-I. The problem
is that they don't trigger the custom parser because all the candidates
are disabled by feature bits. On all other subtargets, the diagnostics are
accurate but are subject to the usual issues of needing to report multiple
ways to correct the code (e.g. smaller offset, enable a CPU feature) but
only being able to report one error.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265018

Don't vary debug info for lldb-server tests

Summary:
Debug info is used only by the client and lldb-server tests do not even have the client component
running, as they communicate with the server directly. Therefore, running the tests for each
debug info type is unnecessarry.

This adds general ability to mark a test class as not dependent on debug info, and marks all
lldb-server tests as such.

Reviewers: tberghammer, tfiala

Subscribers: lldb-commits

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

llvm-svn: 265017

[IFUNC] Introduce GlobalIndirectSymbol as a base class for alias and ifunc

This patch is a part of http://reviews.llvm.org/D15525

GlobalIndirectSymbol class contains common implementation for both
aliases and ifuncs. This patch should be NFC change that just prepare
common code for ifunc support.

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

llvm-svn: 265016

[AMDGPU] Disassembler: support for DPP

Review: http://reviews.llvm.org/D18642
llvm-svn: 265015

[mips] Split mem_msa into range checked mem_simm10 and mem_simm10_lsl[123]

Summary:
Also, made test_mi10.s formatting consistent with the majority of the
MC tests.

Reviewers: vkalintiris

Subscribers: dsanders, llvm-commits

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

llvm-svn: 265014

Prevent X86ISelLowering from merging volatile loads

Change isConsecutiveLoads to check that loads are non-volatile as this
is a requirement for any load merges. Propagate change to two callers.

Reviewers: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 265013

Pass a const SymbolBody to needsGot. NFC.

llvm-svn: 265012

Fix DWO breakage in r264909

Summary:
In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup
the compilation unit in the DWO based on the main object file offset (and failed). I change the
implementation to verify the DIERef indeed references compile unit belonging to this dwo and then
lookup the die based on the die offset alone.

Includes a couple of fixes for mismatched struct/class tags.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

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

llvm-svn: 265011

[mips] Range check simm9 and fix a bug this revealed.

Summary:
The bug was that microMIPS's [ls]w[lr]e instructions claimed to support a
12-bit offset when it is only 9-bit.

Reviewers: vkalintiris

Subscribers: llvm-commits, dsanders

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

llvm-svn: 265010

Fix the alignment check.

We have to check the final value that is written.

I don't think this has any real word implications (unless something
supports unaligned instructions), but unblocks simplifying the handling
of PC relative relocations.

llvm-svn: 265009

[docs] Fix a typo, change the style of the clang-tidy release notes a bit.

llvm-svn: 265008

note for top-level consts in function decls tidy

Summary: Add missing release note

Reviewers: alexfh

Subscribers: LegalizeAdulthood, cfe-commits

Patch by Matt Kulukundis!

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

llvm-svn: 265007

[OpenCL] Added nosvm attribute for OpenCL v2.0.

It is not widely used and removed from OpenCL v2.1.

This change modifies Clang to parse the attribute for OpenCL
but ignores it afterwards.

Patch by Liu Yaxun (Sam)!

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

llvm-svn: 265006

[TTI] Let the cost model estimate ctpop costs based on legality

PPC has a vector popcount, this lets the vectorizer use the correct cost
for it. Tweak X86 test to use an intrinsic that's actually scalarized (we
have a somewhat efficient lowering for vector popcount using SSE, the
cost model finds that now).

llvm-svn: 265005

[OPENMP] Support dumping OpenMP specific constructs.

Add proper dumping support for OpenMP declarations, directives and
clauses.

llvm-svn: 265004

[OPENMP] Allow skip expression after comma in clauses with lists.

Compatibility fix for better compatibility with the existing software.

llvm-svn: 265003

[mips][microMIPS] Implement MFC*, MFHC* and DMFC* instructions
Differential Revision: http://reviews.llvm.org/D17334

llvm-svn: 265002

Silence warnings in OCaml bindings

* LLVMDisposeMessage lives in llvm-c/Core.h, include this file where necessary
* LLVMAddTargetData has been removed, follow suit in the bindings

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

llvm-svn: 265001

Indentation fix in SystemZInstrInfo.cpp

llvm-svn: 265000

[CodeGenCXX] Fix ItaniumCXXABI::getAlignmentOfExnObject to return 8-byte
alignment on Darwin.

Itanium C++ ABI specifies that _Unwind_Exception should be double-word
aligned (16B). To conform to the ABI, libraries implementing exception
handling declare the struct with __attribute__((aligned)), which aligns
the unwindHeader field (and the end of __cxa_exception) to the default
target alignment (which is typically 16-bytes).

struct __cxa_exception {
  ...
  // struct is declared with __attribute__((aligned)).
  _Unwind_Exception unwindHeader;
};

Based on the assumption that _Unwind_Exception is declared with
__attribute__((aligned)), ItaniumCXXABI::getAlignmentOfExnObject returns
the target default alignment for __attribute__((aligned)). It turns out
that libc++abi, which is used on Darwin, doesn't declare the struct with
the attribute and therefore doesn't guarantee that unwindHeader is
aligned to the alignment specified by the ABI, which in some cases
causes the program to crash because of unaligned memory accesses.

This commit avoids crashes due to unaligned memory accesses by having
getAlignmentOfExnObject return an 8-byte alignment on Darwin. I've only
fixed the problem for Darwin, but we should also figure out whether other
platforms using libc++abi need similar fixes.

rdar://problem/25314277

Differential revision: http://reviews.llvm.org/D18479

llvm-svn: 264998

Visual Studio native visualization for clang::TemplateDecl

With this change, TemplateDecls display in the Locals Window something like

  template<typename T, typename U> struct A;

llvm-svn: 264997

[InstCombine] Fix incorrect rule from rL236202

The rule for SMIN introduced in rL236202 doesn't work as advertised: the
check for Pred == ICmpInst::ICMP_SGT was missing.

llvm-svn: 264996

Delete trailing whitespace

llvm-svn: 264995

[SCEV] Track NoWrap properties using MatchBinaryOp, NFC

This way once we teach MatchBinaryOp to map more things into arithmetic,
the non-wrapping add recurrence construction would understand it too.
Right now MatchBinaryOp still only understands arithmetic, so this is
solely a code-reorganization change.

llvm-svn: 264994

[SCEV] NFC code motion to simplify later change

llvm-svn: 264993

[X86] Use MVT instead of EVT in code called after legalization.

llvm-svn: 264992

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