Remove excess semicolons

llvm-svn: 295058

Summary:
There is no guarantee that the tls_init is executed on the static runtime
(/MT).

On windows 7, this unittest is failing.
On windows 10, I believe it's working because of the new CRT.

On ASAN side, it doesn't matter that the hook point is run or not.
It must be run only if there is other tls_initializer that are registered.

Reviewers: rnk, chrisha

Reviewed By: rnk

Subscribers: kubamracek, llvm-commits

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

llvm-svn: 295057

back into a vector

Previously the cost of the existing ExtractElement/ExtractValue
instructions was considered as a dead cost only if it was detected that
they have only one use. But these instructions may be considered
dead also if users of the instructions are also going to be vectorized,
like:
```
%x0 = extractelement <2 x float> %x, i32 0
%x1 = extractelement <2 x float> %x, i32 1
%x0x0 = fmul float %x0, %x0
%x1x1 = fmul float %x1, %x1
%add = fadd float %x0x0, %x1x1
```
This can be transformed to
```
%1 = fmul <2 x float> %x, %x
%2 = extractelement <2 x float> %1, i32 0
%3 = extractelement <2 x float> %1, i32 1
%add = fadd float %2, %3
```
because though `%x0` and `%x1` have 2 users each other, these users are
part of the vectorized tree and we can consider these `extractelement`
instructions as dead.

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

llvm-svn: 295056

llvm-svn: 295055

This reverts commit ce06d9cb99298eb844b66e117f5108a06747c907.

llvm-svn: 295054

llvm-svn: 295053

Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.

The same we did earlier for PC ones,
currenly LLD fails to link linux kernel, 
reporting relocation out of range because of this.

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

llvm-svn: 295052

Don't bother setting the V1/V2 operands again for unary shuffles.

Don't bother legalizing the value type unless the match succeeds.

llvm-svn: 295051

llvm-svn: 295050

Reviewers: alexfh

Subscribers: JDevlieghere, cfe-commits

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

llvm-svn: 295049

Summary:
Users might get confused easily when they see the check's message on
full template function speciliations.

Add a note to the output message, which mentions these kind of function
specializations are treated as regular functions.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: JDevlieghere, cfe-commits

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

llvm-svn: 295048

I think I have a fix for this, but it needs review. This should keep the
bots happy until then.

llvm-svn: 295047

It also shows an unnecessary pshufb/broadcast being used - the original pshufb mask only requested the lowest byte.

llvm-svn: 295046

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

llvm-svn: 295045

llvm-svn: 295044

llvm-svn: 295043

This reverts r295038. The buildbot clang-with-thin-lto-ubuntu failed.
I'm reverting to investigate.

llvm-svn: 295042

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

llvm-svn: 295041

[ELF][MIPS] Use `InputSectionBase::getOutputSection()` to access output sections from the `MipsGotSection`

Follow-up to r294005. This patch restores handling of MISP GOT
relocations against merge sections.

llvm-svn: 295040

Prevent memory objects of different address spaces to be part of
the same load/store groups when analysing interleaved accesses.

This is fixing pr31900.

Reviewers: HaoLiu, mssimpso, mkuper

Reviewed By: mssimpso, mkuper

Subscribers: llvm-commits, efriedma, mzolotukhin

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

llvm-svn: 295038

Removing whitespace.

llvm-svn: 295037

llvm-svn: 295036

llvm-svn: 295035

block or lambda.

This is a follow-up to r281682, which fixed a bug in computeBlockInfo
where the captured VarDecl's type, rather than the captured field type
of the enclosing lambda or block, was used to compute the layout of a
block.

This commit makes similar changes to enterBlockScope. This is necessary
to correctly determine whether a block capture requires cleanup.

rdar://problem/30388124

llvm-svn: 295034

Summary:
Function isCompatibleIVType is already used as a guard before the call to

 SE.getMinusSCEV(OperExpr, PrevExpr);

in LSRInstance::ChainInstruction. getMinusSCEV requires the expressions
to be of the same type, so we now consider two pointers with different
address spaces to be incompatible, since it is possible that the pointers
in fact have different sizes.

Reviewers: qcolombet, eli.friedman

Reviewed By: qcolombet

Subscribers: nhaehnle, Ka-Ka, llvm-commits, mzolotukhin

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

llvm-svn: 295033

llvm-svn: 295032

llvm-svn: 295031

Launch policies provided a mechanism for running RPC handlers on a background
thread (unblocking the main RPC receiver thread). Async handlers generalize
this by passing the responder function (the function that sends the RPC return
value) as an argument to the handler. The handler can optionally do its work on
a background thread (the same way launch policies do), but can also (a) can
inspect the call arguments before deciding to run the work on a different
thread, or (b) can use the responder in a subsequent RPC call (e.g. in the
handler of a callAsync), allowing the handler to call back to the originator (or
to a 3rd party) without blocking the listener thread, and without launching a
new thread.

llvm-svn: 295030

It looks like the only use of AddDeallocation is to indirectly call the
destructors of objects. In one case I found
(TypeAliasTemplateDecl::Common), the destructor is a nop, so registering
it to run later seems pointless.

All of the other *::Common types have non-trivial dtors, so deleting the
useless AddDeallocation felt somewhat fragile. Happy to kill it + turn
the is_trivial_dtor check into a static_assert if people think that'd be
better.

llvm-svn: 295029

llvm-svn: 295028

llvm-svn: 295027

Also, for better uniformity use TargetRegistry::RegisterMCAsmInfo rather than 
RegisterMCAsmInfoFn. Again, no functional change.

llvm-svn: 295026

run it through the ABI's FixCodeAddress method.
<rdar://problem/29711506> 

llvm-svn: 295025

llvm-svn: 295023

These files contain a lexer, so the new names are better.
The parser is in LinkerScript.{cpp,h}.

llvm-svn: 295022

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

llvm-svn: 295021

  Line 38: multiple overloads of 'f' instantiate to the same signature 'void (int) __attribute__((thiscall))'

llvm-svn: 295020

We can't assume that the `const char *` provided through libLTO has a
lifetime that expands beyond the codegenerator itself.

llvm-svn: 295018

compile on powerpc64le.

I cannot locally reproduce this test failure:
http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux/builds/1363/steps/test%20standalone%20compiler-rt/logs/stdio

Let's see how the buildbot goes.

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

llvm-svn: 295017

guide from a constructor.

The purpose of this change is to avoid triggering instantiation of the class
when substituting back into the deduction guide if it uses a typedef member.
We will still instantiate the class if the constructor (explicitly or
implicitly, directly or indirectly) uses the current instantiation in a way
that we can't canonicalize out, but that seems unavoidable.

llvm-svn: 295016