Reduced from oss-fuzz #5032 test case

llvm-svn: 322078

sanitizer-x86_64-linux-fast builder.

llvm-svn: 322077

Ensure these use insertions, not masked load ops

llvm-svn: 322076

follow-up to r321271 based on post-commit feedback by Jim Ingham.

llvm-svn: 322075

Track in the AST whether the operand to a UnaryOperator can overflow and then use that logic when evaluating constant expressions and emitting codegen.

llvm-svn: 322074

Summary:
Add the predicated ADD/SUB instructions and corresponding tests.

Patch [3/3] in a series to add predicated ADD/SUB instructions for SVE.

Reviewers: rengolin, mcrosier, evandro, fhahn, echristo

Reviewed By: fhahn

Subscribers: aemerson, javed.absar, tschuett, llvm-commits, kristof.beyls

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

llvm-svn: 322073

llvm-svn: 322072

We are printing / parsing the `frame-setup` MachineInstr flag but not
the `frame-destroy` one.

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

llvm-svn: 322071

Summary:
Parsing of the '/m' (merging) or '/z' (zeroing) suffix of a predicate operand.

Patch [2/3] in a series to add predicated ADD/SUB instructions for SVE.

Reviewers: rengolin, mcrosier, evandro, fhahn, echristo, MatzeB, t.p.northover

Reviewed By: fhahn

Subscribers: t.p.northover, MatzeB, aemerson, javed.absar, tschuett, llvm-commits, kristof.beyls

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

llvm-svn: 322070

Summary:
This commit enables some of the arithmetic instructions for Nios2 ISA (for both
R1 and R2 revisions), implements facilities required to emit those instructions
and provides LIT tests for added instructions.

Reviewed By: hfinkel

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

Author: belickim <mateusz.belicki@intel.com>
llvm-svn: 322069

Fix type mismatch in omp_control_tool() implementation that makes it run incorrectly on 32-bit machines.

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

llvm-svn: 322068

Summary:
We currently only collect external-linkage symbols in the collector,
which results in missing some typical symbols (like no-linkage type alias symbols).

This patch relaxes the constraint a bit to allow collecting more symbols.

Reviewers: ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: klimek, cfe-commits

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

llvm-svn: 322067

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

llvm-svn: 322066

llvm-svn: 322065

The Ananas Operating System (https://github.com/zhmu/ananas) has shared
library support as of commit 57739c0b6ece56dd4872aedf30264ed4b9412c77.

This change adds the necessary settings to clang so that shared
executables and libraries can be build correctly.

Submitted by:	Rink Springer
Differential Revision:	https://reviews.llvm.org/D41500

llvm-svn: 322064

Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.

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

Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063

CET (Control-Flow Enforcement Technology) introduces a new mechanism called IBT (Indirect Branch Tracking).
According to IBT, each Indirect branch should land on dedicated ENDBR instruction (End Branch).
The new pass adds ENDBR instructions for every indirect jmp/call (including jumps using jump tables / switches).
For more information, please see the following:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

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

Change-Id: Icb754489faf483a95248f96982a4e8b1009eb709
llvm-svn: 322062

When cross-compiling for Windows on Unix, the built toolchain will need
to be transferred to Windows to actually run. My opinion is that the
Unix build should use symlinks, and the transfer to Windows should take
care of making those symlinks usable. E.g., I envision tarballs to be a
common form of transfer from Unix to Windows, in which case the tarball
can be created using --dereference to follow the symlinks.

The motivation here is that, when cross-compiling for Windows on Unix,
the installation will *already* create symlinks. The reason is that the
installation script will be invoked without knowing the host system, so
the `if(UNIX)` check in the installation symlink creation script will
reflect the build system rather than the host system. We could either
make the build and install trees both contain copies or both contain
symlinks, and using symlinks is a significant space saving without (in
my opinion) having any detrimental effect on the usage of the cross-
compiled toolchain on Windows.

A secondary motivation is that Windows 10 version 1703 and later finally
lift the administrator rights requirement for creating symbolic links
(if the system is in Developer Mode), which makes symlinks a lot more
practical even on Windows. Of course Unix and Windows symlinks aren't
interoperable, but symlinks for Windows toolchains is a reasonable
future direction to be going in anyway.

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

llvm-svn: 322061

The code that checks the immediate wasn't masking to the lower 3-bits like the code in X86InstrInfo.cpp that's used by the peephole pass does.

llvm-svn: 322060

SCEV tracks the correspondence of created SCEV to original instruction.
However during creation of SCEV it is possible that nuw/nsw/exact flags are
lost.

As a result during expansion of the SCEV the instruction with nuw/nsw/exact
will be used where it was expected and we produce poison incorreclty.

Reviewers: sanjoy, mkazantsev, sebpop, jbhateja
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41578

llvm-svn: 322058

Summary:
All other templated methods have explicit instantiations but this one is
missing. Discovered while building with a clang with inliner
modifications.

Reviewers: espindola

Subscribers: emaste, llvm-commits, davidxl

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

llvm-svn: 322057

If the offset is differ in two addressing mode we can continue only if
ScaleReg is not set due to we will use it as merge of different offsets.

It should fix PR35799 and PR35805.

Reviewers: john.brawn, reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41227

llvm-svn: 322056

The CTRLoop pass performs checks on the argument of certain libcalls/intrinsics,
and assumes the arguments must be of a simple type. This isn't always the case
though. For example if we unroll and vectorize a loop we may end up with vectors
larger then the largest legal type, along with intrinsics that operate on those
wider types. This happened in the ffmpeg build, where we unrolled a loop and
ended up with a sqrt intrinsic that operated on V16f64, triggering an assertion.

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

llvm-svn: 322055

llvm-svn: 322054

llvm-svn: 322053

r322028 attempted to remove something from the "Manglings"
list when it was no longer valid, and did so with 'erase'.

However, StringRefs to these were stored, so these became
dangling references.  This patch changes to using 'remove' instead
of 'erase' to keep the strings valid.

llvm-svn: 322052

[PowerPC] This reverts commit r322036.

Failing build bots. Revert the commit now.

llvm-svn: 322051

I had to drop fast-isel-abort from a test because we can't fast isel some of the mask stuff. When we used intrinsics we implicitly fell back to SelectionDAG for the intrinsic call without triggering the abort error. But with native IR that doesn't happen the same way.

llvm-svn: 322050

The pattern was this

 def : Pat<(i32 (zext (i8 (bitconvert (v8i1 VK8:$src))))),
           (MOVZX32rr8 (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS VK8:$src, GR32)), sub_8bit))>, Requires<[NoDQI]>;

but if you just let (i32 (zext X)) match byte itself you'll get MOVZX32rr8. And if you let (i8 (bitconvert (v8i1 VK8:$src))) match by itself you'll get (EXTRACT_SUBREG (i32 (COPY_TO_REGCLASS VK8:$src, GR32)), sub_8bit).

So we can just let isel do the two patterns naturally.

llvm-svn: 322049

This commit does two things. Firstly, it adds a collection of flags which can
be passed along to the target to encode information about the MBB that an
instruction lives in to the outliner.

Second, it adds some of those flags to the AArch64 outliner in order to add
more stack instructions to the list of legal instructions that are handled
by the outliner. The two flags added check if

- There are calls in the MachineBasicBlock containing the instruction
- The link register is available in the entire block

If the link register is available and there are no calls, then a stack
instruction can always be outlined without fixups, regardless of what it is,
since in this case, the outliner will never modify the stack to create a
call or outlined frame.

The motivation for doing this was checking which instructions are most often
missed by the outliner. Instructions like, say

%sp<def> = ADDXri %sp, 32, 0; flags: FrameDestroy

are very common, but cannot be outlined in the case that the outliner might
modify the stack. This commit allows us to outline instructions like this.
  

llvm-svn: 322048

This splits relocation processing in two steps.

First, analyze what needs to be done at the relocation spot. This can
be a constant (non preemptible symbol, relative got reference, etc) or
require a dynamic relocation. At this step we also consider creating
copy relocations.

Once that is done we decide if we need a got or a plt entry.

The code is simpler IMHO. For example:

- There is a single call to isPicRel since the logic is not split
  among adjustExpr and the caller.
- R_MIPS_GOTREL is simple to handle now.
- The tracking of what is preemptible or not is much simpler now.

This also fixes a regression with symbols being both in a got and copy
relocated. They had regressed in r268668 and r268149.

The other test changes are because of error messages changes or the
order of two relocations in the output.

llvm-svn: 322047

When cross-compiling, we cannot use the just built toolchain, instead
we need to use the host toolchain which we assume has a support for
targeting the selected target platform. We also need to pass the path
to the native version of llvm-config to external projects.

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

llvm-svn: 322046

The addresses of undefined symbols that make it into the final
executable (i.e. weak references to non-existent symbols) should
resolve to zero.

Also, make sure to not include function in the indirect function
table if they are not included in the output.

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

llvm-svn: 322045

Don't link tests against libgcc when compiler-rt is being used.

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

llvm-svn: 322044

Add attribute target multiversioning to the release notes. 
Additionally adds multiversioning support to the attribute
documentation for 'target'.

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

llvm-svn: 322043

The whole consists of the parts, not the other way around.

llvm-svn: 322042

Currently LLVM's paralellForEach has a problem with reentracy.
That caused https://bugs.llvm.org/show_bug.cgi?id=35788 (lld somtimes
hangs while linking Ruby 2.4) because maybeCompress calls writeTo which
uses paralellForEach.

This patch is to avoid using paralellForEach to call maybeCompress
to workaround the issue.

llvm-svn: 322041

These tests started failing because we now properly convert
DefRange records to and from Yaml, but there were some old yaml
files that had incorrect record definitions generated by the
old buggy obj2yaml.  Rather than try to re-generate the yaml files,
it's easier to just remove the records, and they weren't necessary
for the proper execution of the test anyway.

llvm-svn: 322040

Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.

This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.

llvm-svn: 322039

llvm-svn: 322038