Reasoning behind this change was allowing the function to accept all values
from range [-128, 255] since all of them can be encoded in an 8bit wide
value.
This differs from the prior state where only range [-128, 127] was accepted,
where values were assumed to be signed, whereas now the actual
interpretation of the immediate is deferred to the consumer as required.

Patch by Stefan Maksimovic.

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

llvm-svn: 299229

Summary: Currently the VP metadata was dropped when InstCombine converts a call to direct call. This patch converts the VP metadata to branch_weights so that its hotness is recorded.

Reviewers: eraman, davidxl

Reviewed By: davidxl

Subscribers: llvm-commits

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

llvm-svn: 299228

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

llvm-svn: 299227

This patch serializes the state of #pragma pack. It preserves the state of the
pragma from a PCH/from modules in a file that uses that PCH/those modules.

rdar://21359084

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

llvm-svn: 299226

Convention in libunwind is to use !defined(FOOT) not !FOO.

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

llvm-svn: 299225

llvm-svn: 299224

Implementation of TargetInstrInfo::findCommutedOpIndices for MIPS target,
restricting commutativity to second and third operand only for
dpaadd_[su].df instructions therein.

Prior to this change, there were cases where the vector that is to be added
to the dot product of the other two could take a position other than the
first one in the instruction, generating false output in the destination
vector.

Such behavior has been noticed in the two functions generating v2i64 output
values so far. Other ones may exhibit such behavior as well, just not for
the vector operands which are present in the test at the moment.

Tests altered so that the function's first operand is a constant splat so
that it can be loaded with a ldi instruction, since that is the case in
which the erroneous instruction operand placement has occurred. We check
that the register which is present in the ldi instruction is placed as the
first operand in the corresponding dpadd instruction.

Patch by Stefan Maksimovic.

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

llvm-svn: 299223

llvm-svn: 299222

Followup to D31311

llvm-svn: 299221

Since LOCR only accepts GR32 virtual registers, its operands must be copied
into this regclass in insertSelect(), when an LOCR is built. Otherwise, the
case where the source operand was GRX32 will produce invalid IR.

Review: Ulrich Weigand
llvm-svn: 299220

Currently ComputeNumSignBits returns the minimum number of sign bits for all elements of vector data, when we may only be interested in one/some of the elements.

This patch adds a DemandedElts argument that allows us to specify the elements we actually care about. The original ComputeNumSignBits implementation calls with a DemandedElts demanding all elements to match current behaviour. Scalar types set this to 1.

I've only added support for BUILD_VECTOR and EXTRACT_VECTOR_ELT so far, all others will default to demanding all elements but can be updated in due course.

Followup to D25691.

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

llvm-svn: 299219

llvm-svn: 299218

I am hoping the bot failures are addressed by using cc1 for the ThinLTO
backend invocations as well.

llvm-svn: 299217

This will be used to avoid various call to basename in the asan tests.

llvm-svn: 299216

We don't need && since that is how various run lines are combined.
The redirects were not being used.

llvm-svn: 299215

Also, while at it, s/IsCpp/isCpp/ so that it follows LLVM style.

llvm-svn: 299214

Even on older subtargets that lack vector support, there may be vector values
with just one element in the input program. These are converted during DAG
legalization to scalar values.

The pre-legalize SystemZ DAGCombiner methods should in this circumstance not
touch these nodes. This patch adds a check for this in
SystemZTargetLowering::combineEXTRACT_VECTOR_ELT().

Review: Ulrich Weigand
llvm-svn: 299213

This is a test change applicable for ARM targets.

Previously LLVM would generate a mapping symbol when code contains only
data. This was changed as part of

https://reviews.llvm.org/D30724

and to be more close to the ARM ELF ABI.

The test case is changed to check for behavior with minimal changes.

Patch by Shankar Easwaran

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

llvm-svn: 299212

Based on post-commit review comments by Chandler Carruth on
https://reviews.llvm.org/D31236. Thanks!

llvm-svn: 299211

With the release of Visual Studio 2017, we need to at the very least
claim support for it in the current manifest file. With the changes
introducted in this patch we can install the extension again, but a
warning message will be shown stating that it's not supported
(https://twitter.com/parsley72/status/846558416751411200).

To get the rid of the warning more work is necessary, as VS 2017 changed
some things about extensions, see more here:
https://docs.microsoft.com/en-us/visualstudio/extensibility/how-to-migrate-extensibility-projects-to-visual-studio-2017.
While working on those changes, it has been suggested in the
mail list that this first patch is integrated in the meantime.

Patch by Hugo Puhlmann!

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

llvm-svn: 299210

This fixes tests that do things like

mkdir <dir>
cd <dir>
..
<cmd> *.foo

llvm-svn: 299209

llvm-svn: 299208

llvm-svn: 299207

llvm-svn: 299206

The patch rL298481 was reverted due to crash on clang-with-lto-ubuntu build.
The reason of the crash was type mismatch between either a or b and RHS in the following situation:

  LHS = sext(a +nsw b) > RHS.

This is quite rare, but still possible situation. Normally we need to cast all {a, b, RHS} to their widest type.
But we try to avoid creation of new SCEV that are not constants to avoid initiating recursive analysis that
can take a lot of time and/or cache a bad value for iterations number. To deal with this, in this patch we
reject this case and will not try to analyze it if the type of sum doesn't match with the type of RHS. In this
situation we don't need to create any non-constant SCEVs.

This patch also adds an assertion to the method IsProvedViaContext so that we could fail on it and not
go further into range analysis etc (because in some situations these analyzes succeed even when the passed
arguments have wrong types, what should not normally happen).

The patch also contains a fix for a problem with too narrow scope of the analysis caused by wrong
usage of predicates in recursive invocations.

The regression test on the said failure: test/Analysis/ScalarEvolution/implied-via-addition.ll

Reviewers: reames, apilipenko, anna, sanjoy

Reviewed By: sanjoy

Subscribers: mzolotukhin, mehdi_amini, llvm-commits

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

llvm-svn: 299205

llvm-svn: 299204

llvm-svn: 299203

Previously compiler often extracted common immediates into specific register, e.g.:
```
%vreg0 = S_MOV_B32 0xff;
%vreg2 = V_AND_B32_e32 %vreg0, %vreg1
%vreg4 = V_AND_B32_e32 %vreg0, %vreg3
```
Because of this SDWA peephole failed to find SDWA convertible pattern. E.g. in previous example this could be converted into 2 SDWA src operands:
```
SDWA src: %vreg2 src_sel:BYTE_0
SDWA src: %vreg4 src_sel:BYTE_0
```
With this change peephole check if operand is either immediate or register that is copy of immediate.

llvm-svn: 299202

Follow up to D25691, this sets up the plumbing necessary to support vector demanded elements support in known bits calculations in target nodes.

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

llvm-svn: 299201

Reviewers: labath, emaste

Subscribers: jaydeep, bhushan, lldb-commits, slthakur

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

llvm-svn: 299200

Reviewers: labath, clayborg

Subscribers: jaydeep, bhushan, lldb-commits, slthakur

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

llvm-svn: 299199

llvm-svn: 299198

llvm-svn: 299197

Reviewers: labath, clayborg

Subscribers: jaydeep, bhushan, lldb-commits, slthakur

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

llvm-svn: 299196

llvm-svn: 299195

llvm-svn: 299194

llvm-svn: 299193

Summary:
"kernel_arg_type_qual" metadata should contain const/volatile/restrict
tags only for pointer types to match the corresponding requirement of
the OpenCL specification.

OpenCL 2.0 spec 5.9.3 Kernel Object Queries:

CL_KERNEL_ARG_TYPE_VOLATILE is returned if the argument is a pointer
and the referenced type is declared with the volatile qualifier.
[...]
Similarly, CL_KERNEL_ARG_TYPE_CONST is returned if the argument is a
pointer and the referenced type is declared with the restrict or const
qualifier.
[...]
CL_KERNEL_ARG_TYPE_RESTRICT will be returned if the pointer type is
marked restrict.

Reviewers: Anastasia, cfe-commits

Reviewed By: Anastasia

Subscribers: bader, yaxunl

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

llvm-svn: 299192

Since r299174 use after scope checking is on by default. Even though
msan doesn't check for use after scope it gets confused by the lifetime
markers emitted for it, making unit tests fail. This is covered by
ninja check-msan.

llvm-svn: 299191

llvm-svn: 299190