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

A prologue-end line record is emitted with an incorrect associated address,
which causes a debugger to show the beginning of function body to be inside
the prologue.

Patch written by Carlos Alberto Enciso.

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

llvm-svn: 313047

Summary:
When the MaxVectorSize > ConstantTripCount, we should just clamp the
vectorization factor to be the ConstantTripCount.
This vectorizes loops where the TinyTripCountThreshold >= TripCount < MaxVF.

Earlier we were finding the maximum vector width, which could be greater than
the trip count itself. The Loop vectorizer does all the work for generating a
vectorizable loop, but in the end we would always choose the scalar loop (since
the VF > trip count). This allows us to choose the VF keeping in mind the trip
count if available.

This is a fix on top of rL312472.

Reviewers: Ayal, zvi, hfinkel, dneilson

Reviewed by: Ayal

Subscribers: llvm-commits

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

llvm-svn: 313046

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

llvm-svn: 313045

This was causing PR34045 to fire again.

> This is a preparatory step for D34515 and also is being recommitted as its
> first version caused PR34045.
>
> This change:
>  - makes nodes ISD::ADDCARRY and ISD::SUBCARRY legal for i32
>  - lowering is done by first converting the boolean value into the carry flag
>    using (_, C) ← (ARMISD::ADDC R, -1) and converted back to an integer value
>    using (R, _) ← (ARMISD::ADDE 0, 0, C). An ARMISD::ADDE between the two
>    operations does the actual addition.
>  - for subtraction, given that ISD::SUBCARRY second result is actually a
>    borrow, we need to invert the value of the second operand and result before
>    and after using ARMISD::SUBE. We need to invert the carry result of
>    ARMISD::SUBE to preserve the semantics.
>  - given that the generic combiner may lower ISD::ADDCARRY and
>    ISD::SUBCARRYinto ISD::UADDO and ISD::USUBO we need to update their lowering
>    as well otherwise i64 operations now would require branches. This implies
>    updating the corresponding test for unsigned.
>  - add new combiner to remove the redundant conversions from/to carry flags
>    to/from boolean values (ARMISD::ADDC (ARMISD::ADDE 0, 0, C), -1) → C
>  - fixes PR34045
>
> Differential Revision: https://reviews.llvm.org/D35192

Also revert follow-up r313010:

> [ARM] Fix typo when creating ISD::SUB nodes
>
> In D35192, I accidentally introduced a typo when creating ISD::SUB nodes,
> giving them two values instead of one.
>
> This fails when the merge_values combiner finds one of these nodes.
>
> This change fixes PR34564.
>
> Differential Revision: https://reviews.llvm.org/D37690

llvm-svn: 313044

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`.

Please give your comments :)

llvm-svn: 313043

llvm-svn: 313042

llvm-svn: 313041

For now LLD does not setup the least-significant bit for microMIPS
symbols. llvm-objdump does not like that. In attempt to fix
sanitizer-x86_64-linux-fast build-bot let's temporarily check the raw
binary file content.

llvm-svn: 313040

llvm-svn: 313039

These pieces were commented out in r98534 and r129691, i.e. 6+ years ago.

llvm-svn: 313038

llvm-svn: 313037

llvm-svn: 313036

Reduces number of loops during instructions analysis.

llvm-svn: 313035

llvm-svn: 313034

Summary:
Current implementation does not work if CMAKE_OSX_SYSROOT is not specified.

It silently generates invalid command with the following flags:

`-std=c++11 -lc++ -gline-tables-only -isysroot  -fsanitize=address,fuzzer`

and then fails with the following error:

```
warning: no such sysroot directory: '-fsanitize=address,fuzzer' [-Wmissing-sysroot]"
<...>/RepeatedBytesTest.cpp:5:10: fatal error: 'assert.h' file not found
#include <assert.h>
         ^~~~~~~~~~
1 error generated.
```

However, if you have Command Line Tools installed, you have '/usr/include' dir.
In that case, it is not necessary to specify isysroot path.

Also, with the patch, in case of '/usr/include' does not exist, the '-sysroot'
path would be resolved automatically in compiler-rt/cmake/base-config-ix.cmake.

For more context, see the comment at `compiler-rt/cmake/base-config-ix.cmake#L76`

Reviewers: kcc, george.karpenkov

Reviewed By: kcc, george.karpenkov

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

llvm-svn: 313033

llvm-svn: 313032