llvm-svn: 280666

llvm-svn: 280665

On most architectures the linker is required to optimize away any
references to __tls_get_addr in case of static linking. As usual
a special case is MIPS - libc defines __tls_get_addr itself because
there are no TLS optimizations for this architecture.

llvm-svn: 280664

Summary:
Replace uses of the local MIUtilParse::CRegexParser class with the LLVM support class llvm::Regex. This reduces duplication of code, and makes it possible to remove the MIUtilParse::CRegexParser class that requires LLVM internal implementation headers.

Bug: https://llvm.org/bugs/show_bug.cgi?id=29138

Reviewers: dawn, abidh, ki.stfu

Subscribers: labath, ki.stfu, lldb-commits

Differential Revision: https://reviews.llvm.org/D23882
Author:	Michał Górny <mgorny@gentoo.org>

llvm-svn: 280662

llvm-svn: 280661

This test code previously caused a failure in the module verifier,
because SimplifyCFG created this invalid instruction, which tries to
take the address of inline asm:
  %.sink = select i1 %1, i64 ()* asm "mov $0, #1", "=r", i64 ()* asm %"mov $0, #2", "=r"

This has been fixed recently, presumably by James Molloy's patches that
re-wrote and changed parts of SimplifyCFG, so this patch just adds a
regression test for it.

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

llvm-svn: 280660

llvm-svn: 280659

r280613 introduced failures for all builds that don't target x86 by default. Add an explicit target to avoid a missing feature diagnostic.

llvm-svn: 280658

When optimizing, GCC optimizes away aggressively unused static globals.
The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed
in static constructor earlier while the registration of the globals is done
later in the compilation process.  If all the globals with
dynamic initialization are optimized away from some particular TU in between
those two, libasan can fail on an assertion that dynamic_init_globals is
empty.

While I'm going to commit a GCC change which will remove the
__asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this
happens (basically if the optimizers can prove there are no memory
references in between the two calls), there are still testcases where such
pair of calls is left, e.g. for
struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;

int
main ()
{
  return 0;
}
with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true
this still fails the assertion.  Trying to avoid this problem on the
compiler side would decrease code quality I'm afraid, whether it is making
sure for -fsanitize=address we keep around at least one dynamically
initialized global if the
__asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted,
or adding some artificial global which would be used as the condition for
those calls etc.
So, can the assertion be instead just removed, this really shouldn't slow
down the calls measurably (for __asan_before_dynamic_init it is even
cheaper) and the assertion doesn't check something worthwhile anyway (it is
sufficient if there is a single dynamically initialized global in any other
TU to make it happy).

Details in http://gcc.gnu.org/PR77396

Author: Jakub Jelinek
llvm-svn: 280657

Not sure why ADL isn't working here.

llvm-svn: 280656

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

llvm-svn: 280655

The check-polly-tests target runs regression/unit tests but without checking
formatting. This is useful to not having to reload a file in an open editor
(which eg. clears the undo buffer, moves cursor/window position) when running
polly-update-format.

After this change, the following test targets exist:
 - check-polly-unittests to run unittests only
 - check-polly-tests to run unit and regression tests
 - polly-check-format to check formatting using clang-format
 - check-polly to run them all

As a side-effect, when running check-polly, polly-check-format and run in
parallel (instead of polly-check-format first).

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

llvm-svn: 280654

llvm-svn: 280653

android targets use this key, so the test should recognize it.

llvm-svn: 280652

These need to be mapped through to R_ARM_THM_JUMP{11,8} respectively.

Fixes PR30279.

llvm-svn: 280651

Differential Revision: http://reviews.llvm.org/D23983

llvm-svn: 280650

llvm-svn: 280649

[AVX-512] Simplify X86InstrInfo::copyPhysReg for 128/256-bit vectors with AVX512, but not VLX. We should use the VEX opcodes and trust the register allocator to not use the extended XMM/YMM register space.

Previously we were extending to copying the whole ZMM register. The register allocator shouldn't use XMM16-31 or YMM16-31 in this configuration as the instructions to spill them aren't available.

llvm-svn: 280648

[Target] Remove the AvailableRegClasses vector from TargetLoweringBase. It was a private member with no code reading from it.

llvm-svn: 280647

Summary:
A frontend may designate a particular suspend to be final, by setting the second argument of the coro.suspend intrinsic to true. Such a suspend point has two properties:

* it is possible to check whether a suspended coroutine is at the final suspend point via coro.done intrinsic;
* a resumption of a coroutine stopped at the final suspend point leads to undefined behavior. The only possible action for a coroutine at a final suspend point is destroying it via coro.destroy intrinsic.

This patch adds final suspend handling logic to CoroEarly and CoroSplit passes.
Now, the final suspend point example from docs\Coroutines.rst compiles and produces expected result (see test/Transform/Coroutines/ex5.ll).

Reviewers: majnemer

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 280646

llvm-svn: 280645

[X86] Remove FsVMOVAPSrm/FsVMOVAPDrm/FsMOVAPSrm/FsMOVAPDrm. Due to their placement in the td file they had lower precedence than (V)MOVSS/SD and could almost never be selected.

The only way to select them was in AVX512 mode because EVEX VMOVSS/SD was below them and the patterns weren't qualified properly for AVX only. So if you happened to have an aligned FR32/FR64 load in AVX512 you could get a VEX encoded VMOVAPS/VMOVAPD.

I tried to search back through history and it seems like these instructions were probably unselectable for at least 5 years, at least to the time the VEX versions were added. But I can't prove they ever were.

llvm-svn: 280644

Fix Bug 30240 - std::string: append(first, last) error when aliasing.  Add test cases for append/insert/assign/replace while we're at it, and fix a similar bug in insert.

llvm-svn: 280643

That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.

llvm-svn: 280642

  'str' object has no attribute 'decode'.

llvm-svn: 280641

Although it is not explicitly stated in LLVM Coding Standards, LLVM developers
prefer to omit braces around flow control statements with single line body.

For example the following piece of code

```
if (condition)
  std::cout << "Hello, world!" << std::endl;
```

is preferred to

```
if (condition) {
  std::cout << "Hello, world!" << std::endl;
}
```

So far clang-rename has ignored this. This patch makes clang-rename more
"LLVM-ish".

llvm-svn: 280640

For some reason clang-rename fails to rename method of templated class. Add
XFAIL test reproducing the issue.

llvm-svn: 280639

Patch by Eugene Zelenko!

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

Reviewers: omtcyfz
llvm-svn: 280638

The code to calculate 'UsesRemoved' could be simplified.
As-is, that code is a victim of PR30273:
https://llvm.org/bugs/show_bug.cgi?id=30273

llvm-svn: 280637

llvm-svn: 280636

[AVX-512] Remove 128-bit and 256-bit masked floating point add/sub/mul/div builtins and replace with native operations.

We can't do the 512-bit ones because they take a rounding mode argument that we can't represent.

llvm-svn: 280635

llvm-svn: 280634

[AVX-512] Remove 128-bit and 256-bit masked floating point add/sub/mul/div intrinsics and upgrade to native IR.

llvm-svn: 280633

CompileOnDemandLayer.

Also contains a tweak to the orc-lazy jit in LLI to enable the test case.

llvm-svn: 280632

llvm-svn: 280631

It looks like MIPS dynamic loader does not support RELCOUNT tag.
Both gold/bfd linkers does not emit this tag on MIPS. I will investigate
the problem further but for now it is better to behave like GNU linkers.

llvm-svn: 280630

llvm-svn: 280629

llvm-svn: 280628

The transform in question:
icmp (and (trunc W), C2), C1 -> icmp (and W, C2'), C1'

...is still not enabled for vectors, thus no functional change intended.
It's not clear to me if this is a good transform for vectors or even
scalars in general. Changing that behavior may be a follow-on patch.

llvm-svn: 280627

We used to compute the padding contributions to the block sizes during branch
relaxation only at the start of the transformation. As we perform branch
relaxation, we change the sizes of the blocks, and so the amount of inter-block
padding might change. Accordingly, we need to recompute the (alignment-based)
padding in between every iteration on our way toward the fixed point.

Unfortunately, I don't have a test case (and none was provided in the bug
report), and while this obviously seems needed, algorithmically, I don't have
any way of generating a small and/or non-fragile regression test.

llvm-svn: 280626