Summary:
This fixes a crash when invalid -march options like `armv` are provided.

Based on a patch by Will Lovett.


Reviewers: rengolin, samparker, mcrosier

Reviewed By: samparker

Subscribers: aemerson, kristof.beyls, llvm-commits

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

llvm-svn: 321166

We get an assertion in RegBankSelect for code along the lines of
my_32_bit_int = my_64_bit_int, which tends to translate into a 64-bit
load, followed by a G_TRUNC, followed by a 32-bit store. This appears in
a couple of places in the test-suite.

At the moment, the legalizer doesn't distinguish between integer and
floating point scalars, so a 64-bit load will be marked as legal for
targets with VFP, and so will the rest of the sequence, leading to a
slightly bizarre G_TRUNC reaching RegBankSelect.

Since the current support for 64-bit integers is rather immature, this
patch works around the issue by explicitly handling this case in
RegBankSelect and InstructionSelect. In the future, we may want to
revisit this decision and make sure 64-bit integer loads are narrowed
before reaching RegBankSelect.

llvm-svn: 321165

Summary:
Implement lower of unsigned saturation on an interval [0, k] where k + 1 is a power of two using USAT instruction in a similar way to how [~k, k] is lowered using SSAT on ARM models that supports it.

Patch by Marten Svanfeldt

Reviewers: t.p.northover, pbarrio, eastig, SjoerdMeijer, javed.absar, fhahn

Reviewed By: fhahn

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

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

llvm-svn: 321164

This patch resubmits the SVE ZIP1/ZIP2 patch series consisting of
of r320992, r320986, r320973, and r320970 by reverting
https://reviews.llvm.org/rL321024.

The issue that caused r321024 has been addressed in https://reviews.llvm.org/rL321158,
so this patch-series should be safe to resubmit.

llvm-svn: 321163

Somehow got missed out of r320965.

llvm-svn: 321162

llvm-svn: 321161

Summary:
As suggested by Eli Friedman, don't try to handle array allocas here,
because of possible overflows, instead rely on instcombine converting
them to allocations of array types.

Reviewers: efriedma

Subscribers: llvm-commits

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

llvm-svn: 321159

Summary: This fixes an issue as identified by @rnk in https://reviews.llvm.org/rL321029.

Reviewers: rnk, fhahn, rengolin, efriedma, echristo, olista01

Reviewed By: rnk, fhahn

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

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

llvm-svn: 321158

llvm-svn: 321157

llvm-svn: 321156

Implement the 'Current Cache Size' register that has been introduced
as part of the Armv8.3 architecture. I originally missed this, and
(hopefully) should be the final patch for assembler support.

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

llvm-svn: 321155

The value of the symbol in the assignment should include the sentinel entry.

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

llvm-svn: 321154

NFC.
Adding MC regressions tests to cover the CLFLSH and CLFLUSHOPT isa sets.
This patch is part of a larger task to cover MC encoding of all X86 isa sets started in revision: https://reviews.llvm.org/D39952

Reviewers: zvi, RKSimon, craig.topper, m_zuckerman
Differential Revision: https://reviews.llvm.org/D41331

Change-Id: Ifa643dd52f1b7184c52bc1806038dc74b234fc65
llvm-svn: 321153

The gather instruction will implicitly sign extend to the pointer width, we don't need to further extend it. This can prevent unnecessary splitting in some cases.

There's still an issue that lowering on non-VLX can introduce another sign extend that doesn't get combined with shifts from a lowered sign_extend_inreg.

llvm-svn: 321152

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

llvm-svn: 321151

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

llvm-svn: 321150

The thumb bit should only be set for executable code.

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

llvm-svn: 321149

Not sure how to test this cause I think the worst that happens is that we don't revisit the node a second time to look for additional combines. We used UpdateNodeOperands so the updating the DAG work was already done.

llvm-svn: 321148

This patch fixes a bug in the redundant compare elimination reported in https://reviews.llvm.org/rL320786 and re-enables the optimization.

The redundant compare elimination assumes that we can replace signed comparison with unsigned comparison for the equality check. But due to the difference in the sign extension behavior we cannot change the opcode if the comparison is against an immediate and the most significant bit of the immediate is one.

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

llvm-svn: 321147

llvm-svn: 321146

superfluous -<os>-version-min compiler option

rdar://35813850

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

llvm-svn: 321145

llvm-svn: 321141

The variable being casted was accessed in the previous line.

llvm-svn: 321140

Revert r320942, "[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr"

Caused a test failure on Windows:

[ RUN      ] ImportExpr.ImportCXXDependentScopeMemberExpr
C:\b\rr\tmppzcp4w\w\src\third_party\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp(526): error: Value of: testImport("template <typename T> class C { T t; };" "template <typename T> void declToImport() {" "  C<T> d;" "  d.t;" "}", Lang_CXX, "", Lang_CXX, Verifier, functionTemplateDecl(has(functionDecl(has(compoundStmt( has(cxxDependentScopeMemberExpr())))))))
  Actual: false (Could not find match)
Expected: true
C:\b\rr\tmppzcp4w\w\src\third_party\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp(534): error: Value of: testImport("template <typename T> class C { T t; };" "template <typename T> void declToImport() {" "  C<T> d;" "  (&d)->t;" "}", Lang_CXX, "", Lang_CXX, Verifier, functionTemplateDecl(has(functionDecl(has(compoundStmt( has(cxxDependentScopeMemberExpr())))))))
  Actual: false (Could not find match)
Expected: true
[  FAILED  ] ImportExpr.ImportCXXDependentScopeMemberExpr (37 ms)

llvm-svn: 321139

This teaches memcpyopt to make a non-local memdep query when a local query
indicates that the dependency is non-local. This notably allows it to
eliminate many more llvm.memcpy calls in common Rust code, often by 20-30%.

This is r319482 and r319483, along with fixes for PR35519: fix the 
optimization that merges stores into memsets to preserve cached memdep
info, and fix memdep's non-local caching strategy to not assume that larger
queries are always more conservative than smaller ones.

Fixes PR28958 and PR35519.

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

llvm-svn: 321138

llvm-svn: 321137

llvm-svn: 321136

The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).

Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.

With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.

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

llvm-svn: 321135

In this case we are calling a function pointer which
a type that doesn't otherwise exist in the code.
Clearly this code can't would trap if it was ever
called (because there is not such function that
the pointer can resolve to).

But it should valid and compile and link and validation
time.

llvm-svn: 321134

When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.

There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.

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

llvm-svn: 321133

[X86] Remove code from combineSext that looks for MVT::i1 after operation legalization which can never happen.

Type legalization guarantees this to be impossible since MVT::i1 isn't a legal type.

llvm-svn: 321132

These optimizations depend on the ExplicitLocals pass to lower TEE
instructions, which is disabled in the ELF ABI, so disable them too.

llvm-svn: 321131

When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.

Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.

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

llvm-svn: 321130

llvm-svn: 321129

Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.

This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).

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

rdar://problem/35441058

llvm-svn: 321128

llvm-svn: 321127

These values are trivially never null. While at it, also use
InputSection instead of InputSectionBase when possible.

llvm-svn: 321126

This reverts commit e32def3f7ebe1136b7038336eff56a415a962bf2.

llvm-svn: 321125

As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.

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

llvm-svn: 321124

Thanks to Greg Clayton for catchting this!

llvm-svn: 321123