This patch improves compatibility with GNU linkers.

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

llvm-svn: 326348

llvm-svn: 326347

Summary:
For RISCV32, we must force enable int128 for compiling long double routines using the flag -fforce-enable-int128.

Related clang patch: https://reviews.llvm.org/D43105

Reviewers: asb, kito-cheng, apazos, compnerd, howard.hinnant

Reviewed By: kito-cheng

Subscribers: shiva0217, efriedma, mgorny, hintonda, llvm-commits, #sanitizers

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

llvm-svn: 326346

When merging in types from a type server PDB, we would use a
pointer into the type server PDB's mapped file buffer directly
to avoid copying data.  However, we would close the type server
PDB after we finished merging in its types, which would unmap
all of its memory.  This would lead to a use after free.

We fix this by making a strong reference in the PDBLinker class
to all referenced type server PDBs, thereby making it safe to
hold pointers into its memory mapped contents.

This fixes llvm.org/pr36455

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

llvm-svn: 326345

llvm-svn: 326344

FailedISel MachineFunction property is part of the CodeGen pipeline
state as much as every other property, notably, Legalized,
RegBankSelected, and Selected. Let's make that part of the state also
serializable / de-serializable, so if GlobalISel aborts on some of the
functions of a large module, but not the others, it could be easily seen
and the state of the pipeline could be maintained through llc's
invocations with -stop-after / -start-after.

To make MIR printable and generally to not to break it too much too
soon, this patch also defers cleaning up the vreg -> LLT map until
ResetMachineFunctionPass.

To make MIR with FailedISel: true also machine verifiable, machine
verifier is changed so it treats a MIR-module as non-regbankselected and
non-selected if there is FailedISel property set.

Reviewers: qcolombet, ab

Reviewed By: dsanders

Subscribers: javed.absar, rovka, kristof.beyls, llvm-commits

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

llvm-svn: 326343

Binaries for multiple architectures are combined by fatbinary,
so the current code was effectively not needed.

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

llvm-svn: 326342

Emulated TLS is enabled by llc flag -emulated-tls,
which is passed by clang driver.
When llc is called explicitly or from other drivers like LTO,
missing -emulated-tls flag would generate wrong TLS code for targets
that supports only this mode.
Now use useEmulatedTLS() instead of Options.EmulatedTLS to decide whether
emulated TLS code should be generated.
Unit tests are modified to run with and without the -emulated-tls flag.

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

llvm-svn: 326341

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

llvm-svn: 326340

This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.

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

llvm-svn: 326339

The thread_num parameter of ompt_get_task_info() was not being used previously,
but need to be set.

The print_task_type() function (form the task-types.c testcase) was merged into
the print_ids() function (in callback.h). Testing of ompt_get_task_info() was
added to the task-types.c testcase. It was not tested extensively previously.

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

llvm-svn: 326338

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

llvm-svn: 326337

Let X and Y be types. Previously, functions F(X, Y) and G(Y, X) had
the same hash value because their hash values are computed as follows:

  hash(F) = hash(X) + hash(Y)
  hash(G) = hash(Y) + hash(X)

This patch fixes the issue by using hash_combine.

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

llvm-svn: 326336

Update LLD test expectations for new symbol ordering introduced by
Differential D43685.

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

llvm-svn: 326335

This removes a TODO introduced in rL325860

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

llvm-svn: 326334

Summary:
Expressions of the form x < 0 ? 0 :  x; and x < -1 ? -1 : x can be lowered using bit-operations instead of branching or conditional moves

In thumb-mode this results in a two-instruction sequence, a shift followed by a bic or or while in ARM/thumb2 mode that has flexible second operand the shift can be folded into a single bic/or instructions. In most cases this results in smaller code and possibly less branches, and in no case larger than before.

Patch by Martin Svanfeldt

Reviewers: fhahn, pbarrio, rogfer01

Reviewed By: pbarrio, rogfer01

Subscribers: chrib, yroux, eugenis, efriedma, rogfer01, aemerson, javed.absar, kristof.beyls, llvm-commits

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

llvm-svn: 326333

llvm-svn: 326332

llvm-svn: 326331

We really shouldn't need a 2-loop here at all, but that's another cleanup.

llvm-svn: 326330

Also, rename 'foldOpWithConstantIntoOperand' because that's annoyingly 
vague. The constant check is redundant in some cases, but it allows 
removing duplication for most of the calls.

llvm-svn: 326329

Summary:
Some targets does not support labels inside debug sections, but support
references in form `section +|- offset`. Patch adds initial support
for this. Also, this patch disables emission of all additional debug
  sections that may have labels inside of it (like pub sections and
  string tables).

Reviewers: probinson, echristo

Subscribers: JDevlieghere, llvm-commits

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

llvm-svn: 326328

Summary:
rename_check.py {misc,bugprone}-forwarding-reference-overload
rename_check.py {misc,bugprone}-macro-repeated-side-effects
rename_check.py {misc,bugprone}-lambda-function-name
rename_check.py {misc,bugprone}-misplaced-widening-cast

Reviewers: hokein, sammccall, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: klimek, cfe-commits, mgorny

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

llvm-svn: 326327

llvm-svn: 326326

llvm-svn: 326325

llvm-svn: 326324

The aim of this patch is to be minimal to enable incremental development of
the feature on the top of the tree. This patch should be an NFC when the
feature is turned off. It is turned off by default and still considered as
experimental.

Technical details are available in the EuroLLVM Talk: 
http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7

Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html

Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem.

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

llvm-svn: 326323

The MIPS backend has inconsistent usage of instruction predicates
for assembly and code generation. The issue arises from supporting three
encodings, two (MIPS and microMIPS) of which have a near 1:1 instruction
mapping across ISA revisions and a third encoding with a more restricted
set of instructions (MIPS16e).

To enforce consistent usage, each of the ISA_* adjectives has (or will
have) the relevant encoding attached to it along the relevant ISA revision
where the instruction is defined.

Each instruction, pattern or alias will then have the correct ISA adjective
attached to it, and the base instruction description classes will have any
predicates relating to ISA encoding or revision removed.

Pseudo instructions will also be guarded for the encoding or ABI that they are
supported in.

Finally, the hasStandardEncoding() / inMicroMipsMode() / inMips16Mode() methods
of MipsSubtarget will be changed such that only one can be true at any one time.

The result of this is that code generation and assembly will produce the
correct encoding up front, while code generated from pseudo instructions
and other inserted sequences of instructions will be able to rely on the mapping
tables to produce the correct encoding. This should fix numerous bugs where
the result 'happens' to be correct but has edge cases where microMIPS and MIPS
have subtle differences (e.g. microMIPSR6 using 'j', 'jal' instructions.)

This patch starts the process by changing most of the ISA adjectives to make
use of the EncodingPredicate member of PredicateControl. Follow on patches
will annotate instructions with their correct ISA adjective and eliminate
the usage of "let Predicates = [..]", "let AdditionalPredicates = [..]" and
"isCodeGenOnly = 1" in the cases where it was used to control instruction
availability.

Contributions from Nitesh Jain.

Reviewers: atanasyan

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

llvm-svn: 326322

llvm-svn: 326321

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