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

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

llvm-svn: 280625

llvm-svn: 280624

llvm-svn: 280623

macros.

llvm-svn: 280622

call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load.

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

llvm-svn: 280621

This was mistakenly committed. The world isn't ready for this test, the
test code has horrible debugging code in it that should never have
landed in tree, it currently passes because of bugs elsewhere, and it
needs to be rewritten to not be susceptible to passing for the wrong
reasons.

I'll re-land this in a better form when the prerequisite patches land.

So sorry that I got this mixed into a series of commits that *were*
ready to land. I shouldn't have. =[ What's worse is that it stuck around
for so long and I discovered it while fixing the underlying bug that
caused it to pass.

llvm-svn: 280620

make_scope_exit now that we have that utility.

This makes the code much more clear and readable by isolating the check.
It also makes it easy to go through and make sure all the interesting
update routines have a start and end verify so we don't slowly let the
graph drift into an invalid state.

llvm-svn: 280619

a postorder-sequence based update after edge insertion into a generic
helper function.

This separates the SCC-specific logic into two fairly simple lambdas and
extracts the rest into a generic helper template function. I think this
is a net win on its own merits because it disentangles different pieces
of the algorithm. Now there is one place that does the two-step
partition to identify a set of newly connected components and at the
same time update the postorder sequence.

However, I'm also hoping to re-use this an upcoming patch to update
a cached post-order sequence of RefSCCs when doing the analogous update
to the RefSCC graph, and I don't want to have two copies.

The diff is quite messy but this really is just moving things around and
making types generic rather than specific.

llvm-svn: 280618

memcpy with ld/st.

When InstCombine replaces a memcpy with loads+stores it does not copy over the
llvm.mem.parallel_loop_access from the memcpy instruction. This patch fixes
that.

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

llvm-svn: 280617

ObjectCache is an ExecutionEngine utility, so its anchor belongs there. The
practical impact of this change is that ORC users no longer need to link MCJIT
to use ObjectCaches.

llvm-svn: 280616

llvm-svn: 280615

As it turns out, whether we zero-extend or sign-extend i8/i16 constants, which
are illegal types promoted to i32 on PowerPC, is a choice constrained by
assumptions within the infrastructure. Specifically, the logic in
FunctionLoweringInfo::ComputePHILiveOutRegInfo assumes that constant PHI
operands will be zero extended, and so, at least when materializing constants
that are PHI operands, we must do the same.

The rest of our fast-isel implementation does not appear to depend on the fact
that we were sign-extending i8/i16 constants, and all other targets also appear
to zero-extend small-bitwidth constants in fast-isel; we'll now do the same (we
had been doing this only for i1 constants, and sign-extending the others).

Fixes PR27721.

llvm-svn: 280614

This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.

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

llvm-svn: 280613

llvm-svn: 280612

llvm-svn: 280611

Summary:
The inliner may need to determine where a given funclet unwinds to,
and this determination may depend on other funclets throughout the
funclet tree.  The code that performs this walk in getUnwindDestToken
memoizes results to avoid redundant computations.  In the case that
a funclet's unwind destination is derived from its ancestor, there's
code to walk back down the tree from the ancestor updating the memo
map of its descendants to record the unwind destination.  This change
fixes that code to account for the case that some descendant has a
different unwind destination, which can happen if that unwind dest
is a descendant of the EHPad being queried and thus didn't determine
its unwind destination.

Also update test inline-funclets.ll, which is supposed to cover such
scenarios, to include a case that fails an assertion without this fix
but passes with it.

Fixes PR29151.


Reviewers: majnemer

Subscribers: llvm-commits

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

llvm-svn: 280610

llvm-svn: 280609

llvm-svn: 280608

llvm-svn: 280607

Tracked by:
llvm.org/pr30271

llvm-svn: 280606