We called MaskedValueIsZero with two different masks, but underneath that calls computeKnownBits before applying the mask. This means we compute the same known bits twice due to the two calls. Instead just call computeKnownBits directly and apply the two masks ourselves.

llvm-svn: 327251

When we replace the Phi we created with matched ones it is possible that
there are two identical phi nodes in IR. And matcher is smart enough to find that
new created phi matches both of them. So we try to replace our phi node with
matched ones twice and what is bad we delete our phi node twice causing a crash.

As soon as we found that we have two identical Phi nodes it makes sense to do
a clean-up and replace one phi node by other one.
The patch implements it.

Reviewers: john.brawn, reames
Reviewed By: john.brawn
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43758

llvm-svn: 327250

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

llvm-svn: 327249

the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.

X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got

Fixes PR36555

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

llvm-svn: 327248

64-bit MMX vector generation usually ends up lowering into SSE instructions before being spilled/reloaded as a MMX type.

This patch creates a MMX vector from MMX source values, taking the lowest element from each source and constructing broadcasts/build_vectors with direct calls to the MMX PUNPCKL/PSHUFW intrinsics.

We're missing a few consecutive load combines that could be handled in a future patch if that would be useful - my main interest here is just avoiding a lot of the MMX/SSE crossover.

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

llvm-svn: 327247

Cleaned up check prefixes so that they actually share a bit more

llvm-svn: 327246

XOP was already doing this, and now AVX performs v32i8 variable permutes as well.

llvm-svn: 327245

[X86][AVX] createVariablePermute - widen permutes for cases where the source vector is wider than the destination type

llvm-svn: 327244

llvm-svn: 327243

Same as the VPERMILPS/VPERMILPD approach for v8f32/v4f64 cases, rely on PSHUFB using bits[3:0] for indexing - we can ignore the sign bit (zero element) as those index vector values are considered undefined. The select between the lo/hi permute results based on the index size.

llvm-svn: 327242

llvm-svn: 327241

I've kept SplitBinaryOpsAndApply as a wrapper to avoid a lot of makeArrayRef code.

llvm-svn: 327240

[X86][AVX] createVariablePermute - use 2xVPERMIL+PCMPGT+SELECT for v8i32/v8f32 and v4i64/v4f64 variable permutes

As VPERMILPS/VPERMILPD only selects elements based on the bits[1:0]/bit[1] then we can permute both the (repeated) lo/hi 128-bit vectors in each case and then select between these results based on whether the index was for for lo/hi.

For v4i64/v4f64 this avoids some rather nasty v4i64 multiples on the AVX2 implementation, which seems to be worse than the extra port5 pressure from the additional shuffles/blends.

llvm-svn: 327239

[X86][AVX512] createVariablePermute - Non-VLX targets can widen v4i64/v8f64 variable permutes to v8i64/v8f64

Permutes in the upper elements will be undefined, but they will be discarded anyway.

llvm-svn: 327238

llvm-svn: 327237

Helper function to insert a subvector into the bottom elements of a larger zero/undef vector with the same scalar type.

I've converted a couple of INSERT_SUBVECTOR calls to use it, there are plenty more although in some cases I was worried it might make the code more ambiguous. 

llvm-svn: 327236

StartingAccess is already a MemoryUseOrDef.

llvm-svn: 327235

llvm-svn: 327234

Else, the test fails in LLVM_TARGETS_TO_BUILD=X86 builds like so:
bin/llvm-mc: : error: unable to get target for 'arm64-apple-ios7.0.0'

llvm-svn: 327233

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

llvm-svn: 327232

The intent of revision r300311 was to add a check for invalid scheduling class
descriptors. However, it ended up adding a redundant call in a basic block that
should not be reachable.

llvm-svn: 327231

"I'll revert this tomorrow," I said yesterday. This should've reached
all the bots it can by now.

llvm-svn: 327230

In C, we'll wait until the end of the scope to clean up aggregate
temporaries used for returns from calls. This means in cases like:

{
  // Assuming that `Bar` is large enough to warrant indirect returns
  struct Bar b = {};
  b = foo(&b);
  b = foo(&b);
  b = foo(&b);
  b = foo(&b);
}

...We'll allocate space for 5 Bars on the stack (`b`, and 4
temporaries). This becomes painful in things like large switch
statements.

If cleaning up sooner is trivial, we should do it.

llvm-svn: 327229

Thanks to Richard Smith for the post-commit review!

llvm-svn: 327228

llvm-svn: 327227

llvm-svn: 327226

Summary:
There are 3 different operand orders for FMA instructions so figuring out the exact operation being performed requires a lot of thought.

This patch adds a comment to the end of the assembly line to print the exact operation.

I think I've got all the instructions in here except the ones with builtin rounding.

I didn't update all tests, but I assume we can get them as we regenerate tests in the future.

Reviewers: spatel, v_klochkov, RKSimon

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 327225

Summary:
r327219 adds wrappers to sort which shuffle the container before sorting.
This causes lldb bots to break as the call to sort is now ambiguous:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/20725/steps/ninja%20build%20local/logs/stdio

So we need use llvm::sort instead of sort to avoid ambiguity with std::sort.

Note: This patch is just to unbreak the bots. I plan to have subsequent patches which will convert all
calls to std::sort to llvm::sort.

Reviewers: RKSimon, k8stone, jingham, labath, zturner

Subscribers: andreadb, lldb-commits

Tags: #lldb

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

llvm-svn: 327224

This should make the buildbots green again.

llvm-svn: 327223

llvm-svn: 327222

llvm-svn: 327221

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

llvm-svn: 327220

Summary:
std::sort and array_pod_sort both use non-stable sorting algorithms.
This means that the relative order of elements with the same key is
undefined. This patch is an attempt to uncover such scenarios by
randomly shuffling all containers before sorting, if EXPENSIVE_CHECKS
is enabled.

Here's the bugzilla for this: https://bugs.llvm.org/show_bug.cgi?id=35135

Reviewers: dblaikie, dexonsmith, chandlerc, efriedma, RKSimon

Reviewed By: RKSimon

Subscribers: fhahn, davide, RKSimon, vsk, mgorny, llvm-commits

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

llvm-svn: 327219

llvm-svn: 327218

This will help in some future changes for custom lowering.

llvm-svn: 327217

Piecewise affine expressions have directly corresponding mathematical
operators. Introduce these operators as overloads as this makes writing
code with isl::pw_aff expressions more directly readable.

We can now write:

  A = B + C    instead of    A = B.add(C)

llvm-svn: 327216

no scheduler resources were consumed.

llvm-svn: 327215

This change removes method Backend::getProcResourceMasks() and simplifies some
logic in the Views. This effectively removes yet another dependency between the
views and the Backend.
No functional change intended.

llvm-svn: 327214

llvm-svn: 327213

The variable operand could be NaN, so it's always safe to propagate NaN.

llvm-svn: 327212