The VSX versions have the advantage of a full 64-register target whereas the FP
ones have the advantage of lower latency and higher throughput. So what we’re
after is using the faster instructions in low register pressure situations and
using the larger register file in high register pressure situations.

The heuristic chooses between the following 7 pairs of instructions.
PPC::LXSSPX vs PPC::LFSX
PPC::LXSDX vs PPC::LFDX
PPC::STXSSPX vs PPC::STFSX
PPC::STXSDX vs PPC::STFDX
PPC::LXSIWAX vs PPC::LFIWAX
PPC::LXSIWZX vs PPC::LFIWZX
PPC::STXSIWX vs PPC::STFIWX

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

llvm-svn: 318651

Summary:
This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias.

This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests.

Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch.


Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka

Reviewed By: rengolin, SjoerdMeijer

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

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

llvm-svn: 318650

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

llvm-svn: 318649

Attempt to fix warning picked up by buildbot.

llvm-svn: 318648

The Unified Arm Assembler Language is designed so that the majority of
assembler files can be assembled for both Arm and Thumb with the choice
made as a compilation option.

The way this is done in gcc is to pass -mthumb to the assembler with either
-Wa,-mthumb or -Xassembler -mthumb. This change adds support for these
options to clang. There is no assembler equivalent of -mno-thumb, -marm or
-mno-arm so we don't need to recognize these.

Ideally we would do all of the processing in
CollectArgsForIntegratedAssembler(). Unfortunately we need to change the
triple and at that point it is too late. Instead we look for the option
earlier in ComputeLLVMTriple().
    
Fixes PR34519
    
Differential Revision: https://reviews.llvm.org/D40127

llvm-svn: 318647

Summary:
Correct handling of three libpthread(3) functions on NetBSD:

 - pthread_mutex_lock(3),
 - pthread_mutex_unlock(3),
 - pthread_setcancelstate(3).

Code out of the libpthread(3) context uses the libc symbols:

 - __libc_mutex_lock,
 - __libc_mutex_unlock,
 - __libc_thr_setcancelstate.

The threading library (libpthread(3)) defines strong aliases:

 - __strong_alias(__libc_mutex_lock,pthread_mutex_lock)
 - __strong_alias(__libc_mutex_unlock,pthread_mutex_unlock)
 - __strong_alias(__libc_thr_setcancelstate,pthread_setcancelstate)

This caused that these functions were invisible to sanitizers on NetBSD.
Intercept the libc-specific ones and add them as NetBSD-specific aliases
for the common pthread(3) ones.

NetBSD needs to intercept both functions, as the regularly named ones
are used internally in libpthread(3).

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, dvyukov, vitalybuka

Reviewed By: dvyukov

Subscribers: llvm-commits, kubamracek, #sanitizers

Tags: #sanitizers

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

llvm-svn: 318646

This patch adds a new abstraction layer to VPlan and leverages it to model the planned
instructions that manipulate masks (AND, OR, NOT), introduced during predication.

The new VPValue and VPUser classes model how data flows into, through and out
of a VPlan, forming the vertices of a planned Def-Use graph. The new
VPInstruction class is a generic single-instruction Recipe that models a
planned instruction along with its opcode, operands and users. See
VectorizationPlan.rst for more details.

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

llvm-svn: 318645

This patch starts a series of changes to add support for the new
TBAA metadata format proposed in this llvm-dev thread:

http://lists.llvm.org/pipermail/llvm-dev/2017-November/118748.html

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

llvm-svn: 318644

Add instruction selector test for RSBri, which is derived from
AsI1_rbin_irs, and make sure it doesn't get mistaken for SUBri, which is
derived from the very similar AsI1_bin_irs pattern.

llvm-svn: 318643

Remove some of the instruction selector tests for binary operators (and,
or, xor). These are all derived from the same kind of TableGen pattern,
AsI1_bin_irs, so there's no point in testing all of them.

llvm-svn: 318642

This patch depends on: https://reviews.llvm.org/D35348

Support of pattern selection of masked gathers of AVX2 (X86\AVX2 code gen)
Update LoopVectorize to generate gathers for AVX2 processors.

Reviewers: delena, zvi, RKSimon, craig.topper, aaboud, igorb

Reviewed By: delena, RKSimon

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

llvm-svn: 318641

llvm-svn: 318640

In rL316552, we ban intersection of unsigned latch range with signed range check and vice
versa, unless the entire range check iteration space is known positive. It was a correct
functional fix that saved us from dealing with ambiguous values, but it also appeared
to be a very restrictive limitation. In particular, in the following case:

  loop:
    %iv = phi i32 [ 0, %preheader ], [ %iv.next, %latch]
    %iv.offset = add i32 %iv, 10
    %rc = icmp slt i32 %iv.offset, %len
    br i1 %rc, label %latch, label %deopt

  latch:
    %iv.next = add i32 %iv, 11
    %cond = icmp i32 ult %iv.next, 100
    br it %cond, label %loop, label %exit

Here, the unsigned iteration range is `[0, 100)`, and the safe range for range
check is `[-10, %len - 10)`. For unsigned iteration spaces, we use unsigned
min/max functions for range intersection. Given this, we wanted to avoid dealing
with `-10` because it is interpreted as a very big unsigned value. Semantically, range
check's safe range goes through unsigned border, so in fact it is two disjoint
ranges in IV's iteration space. Intersection of such ranges is not trivial, so we prohibited
this case saying that we are not allowed to intersect such ranges.

What semantics of this safe range actually means is that we can start from `-10` and go
up increasing the `%iv` by one until we reach `%len - 10` (for simplicity let's assume that
`%len - 10`  is a reasonably big positive value).

In particular, this safe iteration space includes `0, 1, 2, ..., %len - 11`. So if we were able to return
safe iteration space `[0, %len - 10)`, we could safely intersect it with IV's iteration space. All
values in this range are non-negative, so using signed/unsigned min/max for them is unambiguous.

In this patch, we alter the algorithm of safe range calculation so that it returnes a subset of the
original safe space which is represented by one continuous range that does not go through wrap.
In order to reach this, we use modified SCEV substraction function. It can be imagined as a function
that substracts by `1` (or `-1`) as long as the further substraction does not cause a wrap in IV iteration
space. This allows us to perform IRCE in many situations when we deal with IV space and range check
of different types (in terms of signed/unsigned).

We apply this approach for both matching and not matching types of IV iteration space and the
range check. One implication of this is that now IRCE became smarter in detection of empty safe
ranges. For example, in this case:
  loop:
    %iv = phi i32 [ %begin, %preheader ], [ %iv.next, %latch]
    %iv.offset = sub i32 %iv, 10
    %rc = icmp ult i32 %iv.offset, %len
    br i1 %rc, label %latch, label %deopt

  latch:
    %iv.next = add i32 %iv, 11
    %cond = icmp i32 ult %iv.next, 100
    br it %cond, label %loop, label %exit

If `%len` was less than 10 but SCEV failed to trivially prove that `%begin - 10 >u %len- 10`,
we could end up executing entire loop in safe preloop while the main loop was still generated,
but never executed. Now, cutting the ranges so that if both `begin - 10` and `%len - 10` overflow,
we have a trivially empty range of `[0, 0)`. This in some cases prevents us from meaningless optimization.

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

llvm-svn: 318639

We must collect all AddModes even if they are the same.
This is due to Original value is different but we need all original
values collected as they are used as anchors in common phi finding.

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

llvm-svn: 318638

The comdat sections in these test cases do not comply with the COFF
specification, and link.exe rejects them. I plan to make a change to
how we handle comdat sections which would also cause us to reject them.

llvm-svn: 318637

llvm-svn: 318636

llvm-svn: 318635

This leaf doesn't take an additional argument.

llvm-svn: 318634

[X86] Reorder and reformat the feature bit checks in getHostCPUFeatues to keep the bits in order per register and encourage future additions to be in order too.

llvm-svn: 318633

Summary:
Most changes are mechanical, but in one place I changed the program semantics
by fixing a likely bug:

In `Scop::hasFeasibleRuntimeContext()`, I'm now explicitely handling the
error-case. Before, when the call to `addNonEmptyDomainConstraints()`
returned a null set, this (probably) accidentally worked because
isl_bool_error converts to true. I'm checking for nullptr now.

Reviewers: grosser, Meinersbur, bollu

Reviewed By: Meinersbur

Subscribers: nemanjai, kbarton, pollydev, llvm-commits

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

llvm-svn: 318632

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

llvm-svn: 318631

llvm-svn: 318630

llvm-svn: 318629

As the first test shows, we could transform an llvm intrinsic which never sets errno 
into a libcall which could set errno (even though it's marked readnone?), so that's 
not ideal.

It's possible that we can also transform a libcall which could set errno to an
intrinsic given the fast-math-flags constraint, but that's deferred to determine
exactly which set of FMF are needed.

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

llvm-svn: 318628

The 'ord' and 'uno' predicates have a logic operation for NAN built into their definitions:

FCMP_ORD   =  7,  ///< 0 1 1 1    True if ordered (no nans)
FCMP_UNO   =  8,  ///< 1 0 0 0    True if unordered: isnan(X) | isnan(Y)

So we can simplify patterns like this:

(fcmp ord (known NNAN), X) && (fcmp ord X, Y) --> fcmp ord X, Y
(fcmp uno (known NNAN), X) || (fcmp uno X, Y) --> fcmp uno X, Y

It might be better to split this into (X uno 0) | (Y uno 0) as a canonicalization, but that
would be another patch.

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

llvm-svn: 318627

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

llvm-svn: 318626

llvm-svn: 318625

Also fix the memop in the ins for these instructions. Not sure what effect this has.

llvm-svn: 318624

llvm-svn: 318623

llvm-svn: 318622

Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.

This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.

Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.

Reviewers: mpark

Reviewed By: mpark

Subscribers: cfe-commits

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

llvm-svn: 318621

llvm-svn: 318620

llvm-svn: 318619

llvm-svn: 318618

llvm-svn: 318617

This is the resolution we came to in D38824.

llvm-svn: 318616

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318615

kernel verifier is becoming smarter and soon will support
direct and indirect function calls.
Remove obsolete error from BPF backend.
Make call to use PCRel_4 fixup.
'bpf to bpf' calls are distinguished from 'bpf to kernel' calls
by insn->src_reg == BPF_PSEUDO_CALL == 1 which is used as relocation
indicator similar to ld_imm64->src_reg == BPF_PSEUDO_MAP_FD == 1
The actual 'call' instruction remains the same for both
'bpf to kernel' and 'bpf to bpf' calls.

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318614

Cannonlake comes after skylake and supports avx512 so this is probably a closer model for now.

llvm-svn: 318613

There are several patches out for review right now to implement Icelake features. This adds a CPU to collect them under.

llvm-svn: 318612