[SCEVExpander] Preserve gep nuw during expansion (#102133)

When expanding SCEV adds to geps, transfer the nuw flag to the resulting
gep. (Note that this doesn't apply to IV increment GEPs, which go

[SCEVExpander] Preserve gep nuw during expansion (#102133)

When expanding SCEV adds to geps, transfer the nuw flag to the resulting
gep. (Note that this doesn't apply to IV increment GEPs, which go
through a different code path.)

show more ...

[Tests] Regenerate test checks (NFC)

[Tests] Remove some and/or constant expressions in tests (NFC)

In preparation for their removal in D158081.

[LoopIdiom] Regenerate test checks (NFC)

LoopIdiom: avoid patterned memset if constant is not relocatable.

The pattern we're using for the memset_pattern* call gets put into a static
global variable initialized, which means it has to be re

LoopIdiom: avoid patterned memset if constant is not relocatable.

The pattern we're using for the memset_pattern* call gets put into a static
global variable initialized, which means it has to be representable with
relocations on the target. Most `ConstantExpr` instances do not satisfy this
constraint, so avoid all of them for now.

show more ...

[LoopIdiom] Convert tests to opaque pointers (NFC)

The differences here are due to SCEVExpander producing GEPs with
explicit offset calculation, a known difference with opaque pointers.

[NFC] Port all LoopIdiom tests to `-passes=` syntax

[opt] Don't translate legacy -analysis flag to require<analysis>

Tests relying on this should explicitly use -passes='require<analysis>,foo'.

[LoopIdiom] Fix bailout for aliasing in memcpy transform.

Commit dd5991cc modified the aliasing checks here to allow transforming
a memcpy where the source and destination point into the same object

[LoopIdiom] Fix bailout for aliasing in memcpy transform.

Commit dd5991cc modified the aliasing checks here to allow transforming
a memcpy where the source and destination point into the same object.
However, the change accidentally made the code skip the alias check for
other operations in the loop.

Instead of completely skipping the alias check, just skip the check for
whether the memcpy aliases itself.

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

show more ...

[NFCI] Regenerate LoopIdiomRecognize test checks

[LoopIdiom] Transform loop containing memcpy to memmove

The purpose of patch is to learn Loop Idiom Recognize pass how to recognize simple memmove patterns
in similar way like GCC does: https://godb

[LoopIdiom] Transform loop containing memcpy to memmove

The purpose of patch is to learn Loop Idiom Recognize pass how to recognize simple memmove patterns
in similar way like GCC does: https://godbolt.org/z/dKjGvTGff
It's follow-up of following change: https://reviews.llvm.org/D104464

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

show more ...

[SCEV] Correctly propagate nowrap flags across scopes when folding invariant add through addrec

This fixes a violation of the wrap flag rules introduced in c4048d8f. This is an alternate fix to D106

[SCEV] Correctly propagate nowrap flags across scopes when folding invariant add through addrec

This fixes a violation of the wrap flag rules introduced in c4048d8f. This is an alternate fix to D106852.

The basic problem being fixed is that we infer a set of flags which is valid at some inner scope S1 (usually by correctly propagating them from IR), and then (incorrectly) extend them to a SCEV in scope S2 where S1 != S2. This is not in general safe per the wrap flags semantics recently defined.

In this patch, I include a simple inference step to handle the case where we can prove that S2 is the preheader of the loop S1, and that entry into S2 implies execution of S1. See the code for a more detailed explanation.

One worry I have with this patch is that I might be over-fitting what shows up in tests - and thus hiding negative impact we'd see in the real world. My best defense is that the rule used here very closely follows the one used to propagate the flags from IR to the inner add to start with, and thus if one is reasonable, so probably is the other. Curious what others think about that piece.

The test diffs are roughly as expected. Mostly analysis only, with two transform changes. Oddly, the result looks better in the loop-idiom test, and I don't understand the PPC output enough to have tell. Nothing terrible looking though. (For context, without the scope inference peephole, the test delta includes a couple of vectorization tests. Again, not super concerning, but slightly more so.)

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

show more ...

regen an autogened test which is stale

[LoopIdiom] Don't transform loop into memmove when load from body has more than one use

This change fixes issue found by Markus: https://reviews.llvm.org/rG11338e998df1
Before this patch following c

[LoopIdiom] Don't transform loop into memmove when load from body has more than one use

This change fixes issue found by Markus: https://reviews.llvm.org/rG11338e998df1
Before this patch following code was transformed to memmove:

for (int i = 15; i >= 1; i--) {
p[i] = p[i-1];
sum += p[i-1];
}

However load from p[i-1] is used not only by store to p[i] but also by sum computation.
Therefore we cannot emit memmove in loop header.

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

show more ...

[NFC][LoopIdiom] Add reproducer of wrong memmove transformation

That's precommit test for D107964.

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

[LoopIdiom] Transform memmove-like loop into memmove (PR46179)

The purpose of patch is to learn Loop idiom recognition pass how to recognize simple memmove patterns
in similar way like GCC: https://

[LoopIdiom] Transform memmove-like loop into memmove (PR46179)

The purpose of patch is to learn Loop idiom recognition pass how to recognize simple memmove patterns
in similar way like GCC: https://godbolt.org/z/fh95e83od
LoopIdiomRecognize already has machinery for memset and memcpy recognition, patch tries to extend exisiting capabilities with minimal effort.

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

show more ...

[InferAttrs] Add nocapture/writeonly to string/mem libcalls

One step closer to fix PR47644.

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

[LoopIdiom] Regenerate test checks; NFC

[BasicAA] Rename deprecated -basicaa to -basic-aa

Follow-up to D82607
Revert an accidental change (empty.ll) of D82683

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., fre

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).

Reviewers: jdoerfert

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

llvm-svn: 365336

show more ...

[SCEV] Use NoWrapFlags when expanding a simple mul

Second functional change following on from rL362687. Pass the
NoWrapFlags from the MulExpr to InsertBinop when we're generating a
shl or mul.

Diff

[SCEV] Use NoWrapFlags when expanding a simple mul

Second functional change following on from rL362687. Pass the
NoWrapFlags from the MulExpr to InsertBinop when we're generating a
shl or mul.

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

llvm-svn: 363540

show more ...

Revert "[SCEV] Use wrap flags in InsertBinop"

This reverts commit r362687. Miscompiles llvm-profdata during selfhost.

llvm-svn: 362699

[SCEV] Use wrap flags in InsertBinop

If the given SCEVExpr has no (un)signed flags attached to it, transfer
these to the resulting instruction or use them to find an existing
instruction.

Different

[SCEV] Use wrap flags in InsertBinop

If the given SCEVExpr has no (un)signed flags attached to it, transfer
these to the resulting instruction or use them to find an existing
instruction.

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

llvm-svn: 362687

show more ...

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

The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

llvm-svn: 358552

[LoopIdiom] Be more aggressive when setting alignment in memcpy

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour o

[LoopIdiom] Be more aggressive when setting alignment in memcpy

Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
LoopIdiom pass to cease using the old IRBuilder CreateMemCpy single-alignment APIs in
favour of the new API that allows setting source and destination alignments independently.
This allows us to be slightly more aggressive in setting the alignment of memcpy calls that
loop idiom creates.

Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.

Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html

llvm-svn: 324626

show more ...