llvm-project.git/llvm/test/Transforms/LoopVectorize/tripcount.ll, branch users/nico/python-2

[LoopVectorize] Convert some tests to opaque pointers (NFC)

2022-12-14T14:16:59+00:00

[test][NewPM] Use -passes=loop-vectorize instead of -loop-vectorize

2022-04-28T14:46:00+00:00

Update a bunch of loop-vectorize regression tests to use the new PM
syntax (opt -passes=loop-vectorize) instead of the deprecated legacy
PM syntax (opt -loop-vectorize).

Revert "[NFCI] Regenerate SROA/LoopVectorize test checks"

2022-04-03T23:15:30+00:00

This reverts commit 14e3450fb57305aa9ff3e9e60687b458e43835c9.

[NFCI] Regenerate LoopVectorize test checks

2022-04-03T19:56:24+00:00

Revert "[LV] Remove `LoopVectorizationCostModel::useEmulatedMaskMemRefHack()`"

2022-02-09T20:02:54+00:00

This reverts commit 77a0da926c9ea86afa9baf28158d79c7678fc6b9 as we've
received multiple reports of this significantly impacting performance,
in ways that don't seem to just be target specific cost models going
wrong. I would offer some reproducers, but the test changes here seem to
be full of them!

Reverting for now and hopefully we can remove the "hack" more carefully
as we go.

[LV] Remove `LoopVectorizationCostModel::useEmulatedMaskMemRefHack()`

2022-02-07T13:08:31+00:00

D43208 extracted `useEmulatedMaskMemRefHack()` from legality into cost model.
What it essentially does is prevents scalarized vectorization of masked memory operations:
```
  // TODO: Cost model for emulated masked load/store is completely
  // broken. This hack guides the cost model to use an artificially
  // high enough value to practically disable vectorization with such
  // operations, except where previously deployed legality hack allowed
  // using very low cost values. This is to avoid regressions coming simply
  // from moving "masked load/store" check from legality to cost model.
  // Masked Load/Gather emulation was previously never allowed.
  // Limited number of Masked Store/Scatter emulation was allowed.
```

While i don't really understand about what specifically `is completely broken`
was talking about, i believe that at least on X86 with AVX2-or-later,
this is no longer true. (or at least, i would like to know what is still broken).
So i would like to follow suit after D111460, and like wise disable that hack for AVX2+.

But since this was added for X86 specifically, let's just instead completely remove this hack.

Reviewed By: RKSimon

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

Revert "Use uint64_t for branch weights instead of uint32_t"

2020-10-31T07:25:32+00:00

This reverts commit 10f2a0d662d8d72eaac48d3e9b31ca8dc90df5a4.

More uint64_t overflows.

Use uint64_t for branch weights instead of uint32_t

2020-10-30T17:03:46+00:00

CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.

Reviewed By: davidxl

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

Revert "Use uint64_t for branch weights instead of uint32_t"

2020-10-27T13:26:21+00:00

This reverts commit e5766f25c62c185632e3a75bf45b313eadab774b.
Makes clang assert when building Chromium, see https://crbug.com/1142813
for a repro.

Use uint64_t for branch weights instead of uint32_t

2020-10-27T03:24:04+00:00

CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.

Reviewed By: davidxl

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