Add legalization/selection for x86/x86_64 and
corresponding tests.

Reviewed By: igorb

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

llvm-svn: 326320

llvm-svn: 326319

Summary:
Fix a bug in MergeICmp that can lead to a BCECmp block being processed more than once and eventually lead to a broken LLVM module.
The problem is that if the non-constant value is not produced by the last block, the producer will be processed once when the its parent block
is processed and second time when the last block is processed.

We end up having 2 same BCECmpBlock in the merge queue. And eventually lead to a broken LLVM module.

Reviewers: courbet, davide

Reviewed By: courbet

Subscribers: llvm-commits

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

llvm-svn: 326318

There are many instruction ctors that call the setName method of the Value base class, which can throw a bad_alloc exception in OOM situations. 
In such situations special User delete operators are called which are not implemented yet.

Example:
 Lets look at the construction of a CallInst instruction during IR generation:

static CallInst *Create(FunctionType *Ty, Value *Func, ArrayRef<Value *> Args, .. ){
...

return new (TotalOps, DescriptorBytes) CallInst(Ty, Func, Args, Bundles, NameStr, InsertBefore);

}

CallInst::CalInst(Value* Func, ...) {
...
Op<-1>() = Func;
....
setName(name); // throws
...
}
Op<-1>() returns a reference to a Use object of the CallInst instruction and the operator= inserts this use object into the UseList of Func. 
The same object is removed from that UseList by calling the User::operator delete If the CallInst object is deleted. 
Since setName can throw a bad_alloc exception (if LLVM_ENABLE_EXCEPTIONS is switched on), the unwind chain runs into assertions ("Constructor throws?") in 
special User::operator deletes operators:

operator delete(void* Usr, unsigned)
operator delete(void* Usr, unsigned, bool)
This situation can be fixed by simlpy calling the User::operator delete(void*) in these unimplemented methods.

To ensure that this additional call succeeds all information that is necessary to calculate the storage pointer from the Usr address 
must be restored in the special case that a sublass has changed this information, e.g. GlobalVariable can change the NumberOfOperands.

Reviewd by: rnk

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

llvm-svn: 326316

Removes verifyDomTree, using assert(verify()) everywhere instead, and
changes verify a little to always run IsSameAsFreshTree first in order
to print good output when we find errors. Also adds verifyAnalysis for
PostDomTrees, which will allow checking of PostDomTrees it the same way
we check DomTrees and MachineDomTrees.

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

llvm-svn: 326315

llvm-svn: 326314

Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.

For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X;  // forward decl

// x.h
class X {};
```

This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.

Reviewers: sammccall

Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits

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

llvm-svn: 326313

The main change of this patch is to insert {{.*}} in current_address=[[RETURN_ADDRESS_END]].
This is needed to match any of the alternatively printed addresses.

Additionally, clang-format is applied to the two tests.

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

llvm-svn: 326312

Add legalization/selection for x86/x86_64 and
corresponding tests.

Reviewed By: igorb

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

llvm-svn: 326311

llvm-svn: 326310

llvm-svn: 326309

[X86] Don't use EXTRACT_ELEMENT from v1i1 with i8/i32 result type when we need to guarantee zeroes in the upper bits of return.

An extract_element where the result type is larger than the scalar element type is semantically an any_extend of from the scalar element type to the result type. If we expect zeroes in the upper bits of the i8/i32 we need to mae sure those zeroes are explicit in the DAG.

For these cases the best way to accomplish this is use an insert_subvector to pad zeroes to the upper bits of the v1i1 first. We extend to either v16i1(for i32) or v8i1(for i8). Then bitcast that to a scalar and finish with a zero_extend up to i32 if necessary. We can't extend past v16i1 because that's the largest mask size on KNL. But isel is smarter enough to know that a zext of a bitcast from v16i1 to i16 can use a KMOVW instruction. The insert_subvectors will be dropped during isel because we can determine that the producing instruction already zeroed the upper bits of the k-register.

llvm-svn: 326308

ARC mode.

Declaring __strong pointer fields in structs was not allowed in
Objective-C ARC until now because that would make the struct non-trivial
to default-initialize, copy/move, and destroy, which is not something C
was designed to do. This patch lifts that restriction.

Special functions for non-trivial C structs are synthesized that are
needed to default-initialize, copy/move, and destroy the structs and
manage the ownership of the objects the __strong pointer fields point
to. Non-trivial structs passed to functions are destructed in the callee
function.

rdar://problem/33599681

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

llvm-svn: 326307

[X86] Change the masked FPCLASS implementation to use AND instead of OR to combine the mask results.

While the description for the instruction does mention OR, its talking about how the individual classification test results are ORed together.

The incoming mask is used as a zeroing write mask. If the bit is 1 the classification is written to the output. The bit is 0 the output is 0. This equivalent to an AND.

Here is pseudocode from the intrinsics guide

FOR j := 0 to 1
        i := j*64
        IF k1[j]
                k[j] := CheckFPClass_FP64(a[i+63:i], imm8[7:0])
        ELSE
                k[j] := 0
        FI
ENDFOR
k[MAX:2] := 0

llvm-svn: 326306

We should process symbols inside output section declarations the same way as top-level ones.

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

llvm-svn: 326305

[ARM] Cortex-A57 scheduler fix for ARM backend (missed 16-bit, v8.1/v8.2/v8.3, thumb and pseudo instructions)

Added missed scheduling info for ARM Cortex A57 (AArch32) to have CompleteModel with this checkCompleteness fix: https://reviews.llvm.org/D43235.

Reviewed By: RKSimon

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

llvm-svn: 326304

llvm-svn: 326303

llvm-svn: 326302

llvm-svn: 326301

llvm-svn: 326300

Fix a couple of cases where we would fail to correctly parse deduced class template specialization types.

Specifically, we would not properly parse these types within template arguments
(for non-type template parameters), and in tentative parses. Fixing both of
these essentially requires that we parse deduced template specialization types
as types in all contexts, even in template argument lists -- in particular,
tentative parsing may look ahead and annotate a deduced template specialization
type before we figure out that we're actually supposed to treat the tokens as a
template-name. We deal with this by simply permitting deduced template
specialization types when parsing template arguments, and converting them to
template template arguments.

llvm-svn: 326299

llvm-svn: 326298

This patch simplifies initializeSymbols. Since that function is called
at the tail context of ObjFile::parse, and the function is called only
once from that function, that's effectively just a continuation of
ObjFile::parse. So this patch merge it with ObjFile::parse.

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

llvm-svn: 326296

reference results

llvm-svn: 326295

Specifically the case where the undefined symbol is not found
during the link.

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

llvm-svn: 326294

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

llvm-svn: 326293

[StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 326292

The problem I want to address now is that chunks have too many data
members for "offsets", and their origins are not well defined.
For example, InputSegment has OutputSegmentOffset, but it's base class
also has OutputOffset. That's very confusing.

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

llvm-svn: 326291

relaxing an assertion.

llvm-svn: 326290

These output section names are ELF-specific. We shouldn't have this rule
for WebAssembly.

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

llvm-svn: 326289

Some of the update_*_test_checks regexes have been moved into a
library, so we might as well use them in update_mir_test_checks.
Also includes minor bugfixes to the regexes that are there so we
don't regress update_mir_test_checks

llvm-svn: 326288

llvm-svn: 326287

SubSection inherited from SyntheticSection, and SyntheticSection inherits
from OutputSection, so SubSection was an OutputSection. But that's wrong
because SubSection is not actually a WebAssembly output section.
It shares some functionalities with OutputSection, but overall it's very
different.

This patch removes that inheritance.

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

llvm-svn: 326286

The main purpose of this change is to make initializeSymbols shorter.

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

llvm-svn: 326285

Since vregs are printed in the instruction stream now, checking the
vreg block is always redundant. Remove the temporary feature that
allowed us to do that.

This reverts r316134

llvm-svn: 326284

That variable hides the class of the same name.

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

llvm-svn: 326283

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

llvm-svn: 326282

FileOutputBuffer automatically removes an existing file, so we don't
need to do that. Actually doing that is discouraged because when the
linker fails to create an output for some reason after instantiating
FileOutputBufffer, FileOutputBuffer removes a temporary file and don't
touch an existing file. That's an desired behavior from the user's
point of view.

(Internally, FileOutputBuffer writes its contents to a temporary file
and then rename it over to an existing file on commit()).

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

llvm-svn: 326281

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

llvm-svn: 326280

Summary: [WebAssembly] Simplify createLikingSection.

Reviewers: sbc100

Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

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

llvm-svn: 326279