bcm5719-llvm/llvm/test/Transforms/LoadStoreVectorizer/X86, branch meklort-10.0.1

[lit] Delete empty lines at the end of lit.local.cfg NFC

2019-06-17T09:51:07+00:00

llvm-svn: 363538

Revert "Temporarily Revert "Add basic loop fusion pass.""

2019-04-17T04:52:47+00:00

The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552

Temporarily Revert "Add basic loop fusion pass."

2019-04-17T02:12:23+00:00

As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546

Fix invalid target triples in tests. (NFC)

2019-03-04T23:37:41+00:00

llvm-svn: 355349

[PM] Port LoadStoreVectorizer to the new pass manager.

2018-12-07T08:23:37+00:00

Differential Revision: https://reviews.llvm.org/D54848 llvm-svn: 348570

Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of SCEVs"

2018-08-27T21:41:37+00:00

This reverts r319889. Unfortunately, wrapping flags are not a part of SCEV's identity (they do not participate in computing a hash value or in equality comparisons) and in fact they could be assigned after the fact w/o rebuilding a SCEV. Grep for const_cast's to see quite a few of examples, apparently all for AddRec's at the moment. So, if 2 expressions get built in 2 slightly different ways: one with flags set in the beginning, the other with the flags attached later on, we may end up with 2 expressions which are exactly the same but have their operands swapped in one of the commutative N-ary expressions, and at least one of them will have "sorted by complexity" invariant broken. 2 identical SCEV's won't compare equal by pointer comparison as they are supposed to. A real-world reproducer is added as a regression test: the issue described causes 2 identical SCEV expressions to have different order of operands and therefore compare not equal, which in its turn prevents LoadStoreVectorizer from vectorizing a pair of consecutive loads. On a larger example (the source of the test attached, which is a bugpoint) I have seen even weirder behavior: adding a constant to an existing SCEV changes the order of the existing terms, for instance, getAddExpr(1, ((A * B) + (C * D))) returns (1 + (C * D) + (A * B)). Differential Revision: https://reviews.llvm.org/D40645 llvm-svn: 340777

[SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...) transform

2018-07-24T21:48:56+00:00

if the top level addition in (D + (C-D + x + ...)) could be proven to not wrap, where the choice of D also maximizes the number of trailing zeroes of (C-D + x + ...), ensuring homogeneous behaviour of the transformation and better canonicalization of such expressions. This enables better canonicalization of expressions like 1 + zext(5 + 20 * %x + 24 * %y) and zext(6 + 20 * %x + 24 * %y) which get both transformed to 2 + zext(4 + 20 * %x + 24 * %y) This pattern is common in address arithmetics and the transformation makes it easier for passes like LoadStoreVectorizer to prove that 2 or more memory accesses are consecutive and optimize (vectorize) them. Reviewed By: mzolotukhin Differential Revision: https://reviews.llvm.org/D48853 llvm-svn: 337859

NFC - Various typo fixes in tests

2018-07-04T13:28:39+00:00

llvm-svn: 336268

[LoadStoreVectorizer] Differentiate between <1 x T> and T

2018-03-07T10:29:28+00:00

The LoadStoreVectorizer thought that <1 x T> and T were the same types when merging stores, leading to a crash later. Patch by Erik Hogeman. Differential Revision: https://reviews.llvm.org/D44014 llvm-svn: 326884

[Analysis] Fix merging TBAA tags with different final access types

2017-11-08T11:42:21+00:00

There are cases when we have to merge TBAA access tags with the same base access type, but different final access types. For example, accesses to different members of the same structure may be vectorized into a single load or store instruction. Since we currently assume that the tags to merge always share the same final access type, we incorrectly return a tag that describes an access to one of the original final access types as the generic tag. This patch fixes that by producing generic tags for the common type and not the final access types of the original tags. Resolves: PR35225: Wrong tbaa metadata after load store vectorizer due to recent change https://bugs.llvm.org/show_bug.cgi?id=35225 Differential Revision: https://reviews.llvm.org/D39732 llvm-svn: 317682