Some projects need to add conditional dependencies on other projects.
compiler-rt is already doing this, and I attempted to add this to
debuginfo-tests when I ran into the ordering problem, that you can't
conditionally add a dependency unless that dependency's CMakeLists.txt
has already been run (which would allow you to say if (TARGET foo).

The solution to this seems to be to determine very early on the entire
set of projects which is enabled. This is complicated by the fact that
there are multiple ways to enable projects, and different tree layouts
(e.g. mono-repo, out of -tree, external, etc). This patch attempts to
centralize all of this into one place, and then updates compiler-rt to
demonstrate as a proof of concept how this can simplify code.

Differential Revision: https://reviews.llvm.org/D37637

llvm-svn: 313091

llvm-svn: 313090

The masked store instruction only cares about the sign-bit of each mask element,
so the compare s<0 isn't needed.

As noted in PR11210:
https://bugs.llvm.org/show_bug.cgi?id=11210
...fixing this should allow us to eliminate x86-specific masked store intrinsics in IR.
(Although more testing will be needed to confirm that.)

I filed a bug to track improvements for AVX512:
https://bugs.llvm.org/show_bug.cgi?id=34584

Differential Revision: https://reviews.llvm.org/D37446

llvm-svn: 313089

This reverts rL313082

llvm-svn: 313088

We make the same decision when compiling the kernel or kexts -- we
should do this in -ffreestanding mode as well to avoid size regressions
in a potentially large set of firmware projects.

It's still possible to get uwtable information in -ffreestanding mode by
compiling with -funwind-tables (I expect this to be a rare case: I
certainly haven't seen any projects like that).

Context: -munwind-tables was enabled by default for some arm targets in
r310006.

Testing: check-clang

rdar://problem/33934446

Differential Revision: https://reviews.llvm.org/D37777

llvm-svn: 313087

https://reviews.llvm.org/rL312796 meant that references to garbage collected common symbols would cause a segfault.

This change fixes the behaviour for references to stripped common symbols.

Differential Revision: https://reviews.llvm.org/D37718

llvm-svn: 313086

llvm-svn: 313085

Differential Revision: https://reviews.llvm.org/D37728

llvm-svn: 313084

When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue, 
one can notice that in this case we don't actually need 
to try to load the already loaded module (corresponding to .dwo).

Test plan: make check-all

Differential revision: https://reviews.llvm.org/D37295

llvm-svn: 313083

In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.

llvm-svn: 313082

llvm-svn: 313081

Summary: This change passes down ACT to SampleProfileLoader for the new PM. Also remove the default value for SampleProfileLoader class as it is not used.

Reviewers: eraman, davidxl

Reviewed By: eraman

Subscribers: sanjoy, llvm-commits

Differential Revision: https://reviews.llvm.org/D37773

llvm-svn: 313080

This flag is unnecessary for testing because we can get the coverage
we need by adjusting CU attributes.

Differential Revision: https://reviews.llvm.org/D37725

llvm-svn: 313079

This allows the flag to be persisted through to LTO.

Differential Revision: https://reviews.llvm.org/D37655

llvm-svn: 313078

Currently, UImm16_AltRelaxed match type is not handled in
MatchAndEmitInstruction() function, which may result in
llvm_unreachable() behavior.
This patch adds necessary case for this match type.

Patch by Aleksandar Beserminji.

Differential Revision: https://reviews.llvm.org/D37682

llvm-svn: 313077

It is not needed since it is always 0.

llvm-svn: 313076

Summary:
The current promoteLoopAccessesToScalars method receives an AliasSet, but
the information used is in fact a list of Value*, known to must alias.
Create the list ahead of time to make this method independent of the AliasSet class.

While there is no functionality change, this adds overhead for creating
a set of Value*, when promotion would normally exit earlier.
This is meant to be as a first refactoring step in order to start replacing
AliasSetTracker with MemorySSA.
And while the end goal is to redesign LICM, the first few steps will focus on
adding MemorySSA as an alternative to the AliasSetTracker using most of the
existing functionality.

Reviewers: mkuper, danielcdh, dberlin

Subscribers: sanjoy, chandlerc, gberry, davide, llvm-commits

Differential Revision: https://reviews.llvm.org/D35439

llvm-svn: 313075

Tablegen already can select these: mark them as legal, remove the
c++ code, and add tests for all types.

llvm-svn: 313074

We already support these in tablegen, but we're matching the wrong
operator (libm ftrunc).  Fix that.

While there, drop the c++ code, support COPYs of FPR16, and add tests
for the other types.

llvm-svn: 313073

Differential Revision: https://reviews.llvm.org/D37133

llvm-svn: 313072

llvm-svn: 313069

This check implements the typebased semantic of `gsl::owner`.
Meaning, that 
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
  or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
  must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor

There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.

But cases like fully templated functions
```
template <typename T> 
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.

Codereview in D36354

llvm-svn: 313067

On i386, the --entry parameter to GNU ld is supposed to be a decorated
symbol name, while it is an undecorated name in link.exe.

Differential Revision: https://reviews.llvm.org/D37710

llvm-svn: 313066

While building a project with code coverage enabled, we can link in
dependencies which export a weak definition of __llvm_profile_filename.

After r306710, linking in the profiling runtime could pull in a weak
definition of this symbol from a dependency, instead of from within the
runtime's archive.

This inconsistency causes issues during API verification, and is also a
practical problem (the symbol would go missing were the dependent dylib
to be switched out). Introduce a LinkFirst runtime link option to make
sure we always search the profiling runtime for this symbol first.

rdar://problem/33271080

Differential Revision: https://reviews.llvm.org/D35385

llvm-svn: 313065

llvm-svn: 313064

Summary:
This is nessesary in Python3. Everywhere else we assume that
encoding is UTF8. If we don't specify it here, the defaults
from the environment will be used, which may result in ASCII
decoder being used. And if the file is non-ASCII, then it
will crash:
```
  File "/usr/local/bin/coverage-report-server.py", line 168, in do_GET
    for line_no, line in enumerate(f, start=1)])
  File "/usr/local/bin/coverage-report-server.py", line 165, in <listcomp>
    ["<span class='{cls}'>{line}&nbsp;</span>".format(
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 106: ordinal not in range(128)
```

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

Now, how would i add a testcase here?

Reviewers: m.ostapenko, kcc

Reviewed By: kcc

Subscribers: kcc, llvm-commits

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D37661

llvm-svn: 313063

The default blacklist should also apply when the integer or nullability
checks are enabled.

llvm-svn: 313062

Implementing this pass as a PowerPC specific pass.  Branch coalescing utilizes
the analyzeBranch method which currently does not include any implicit operands.
This is not an issue on PPC but must be handled on other targets.

Pass is currently off by default. Enabled via -enable-ppc-branch-coalesce.

Differential Revision : https: // reviews.llvm.org/D32776

llvm-svn: 313061

We're moving the extension to a new account on the VS Marketplace, and
apparently it's not possible to re-upload an extension with an existing
ID on a new account.

llvm-svn: 313060

This should unbreak the buildbot for visual studio 2015 for now.

llvm-svn: 313059

Looks like these were copied from the ELF sections but
don't apply to Wasm and were not used anywhere.

Also remove unused Wasm methods in MCContext.

Differential Revision: https://reviews.llvm.org/D37633

llvm-svn: 313058

This reverts commit r313047 as it is causing buildbot failure (lldb inline
stepping tests).

llvm-svn: 313057

Apply D28224: 'Throw exception after too many steps' Fixes PR#20291. Thanks to Tim Shen for the patch

llvm-svn: 313056

Reviewed-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
llvm-svn: 313055

Recognizing this pattern during DAG combine hides information about the 'and' and the shift from other combines. I think it should be recognized at isel so its as late as possible. But it can't be done with table based isel because you need to be able to look at both immediates. This patch moves it to custom isel in X86ISelDAGToDAG.cpp.

This does break a couple tests in tbm_patterns because we are now emitting an and_flag node or (cmp and, 0) that we dont' recognize yet. We already had this problem for several other TBM patterns so I think this fine and we can address of them together.

I've also fixed a bug where the combine to BEXTR was preventing us from using a trick of zero extending AH to handle extracts of bits 15:8. We might still want to use BEXTR if it enables load folding. But honestly I hope we narrowed the load instead before got to isel.

I think we should probably also support matching BEXTR from (srl/srl (and mask << C), C). But that should be a different patch.

Differential Revision: https://reviews.llvm.org/D37592

llvm-svn: 313054

Checking if config.target_arch is x86_64h doesn't work (the 'h' suffix
is dropped here, and I didn't account for that). Instead, check to see
if '-arch x86_64h' is in the cflags.

Tested on a pre-Haswell bot.

rdar://problem/34378605

llvm-svn: 313053

llvm-svn: 313052

llvm-svn: 313051

Summary:
The CompilerInstance should create its default VFS from its CompilerInvocation. Right now the
user has to manually create the VFS before creating the FileManager even though
`-ivfsoverlay file.yaml` was passed via the CompilerInvocation (which is exactly how we worked
around this issue in `FrontendAction.cpp` so far).

This patch uses the invocation's VFS by default and also tests this behavior now from the
point of view of a program that uses the clang API.

Reviewers: benlangmuir, v.g.vassilev

Reviewed By: v.g.vassilev

Subscribers: mgorny, cfe-commits, v.g.vassilev

Differential Revision: https://reviews.llvm.org/D37416

llvm-svn: 313049

Given our representation of symbols as section + offset, we can
finalize symbols like _end as soon as the section is known.

llvm-svn: 313048