[Attributor][FIX] Visit same instructions with different scopes

If we collect potential values we need to visit a value even if we have
seen it before if the scope is different. The scope is part of

[Attributor][FIX] Visit same instructions with different scopes

If we collect potential values we need to visit a value even if we have
seen it before if the scope is different. The scope is part of the
result after all. Test included.

Fixes https://github.com/llvm/llvm-project/issues/56753

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

(cherry picked from commit b65471d7152d15790ae599326da86b7e6cfb4580)

show more ...

Remove redundaunt virtual specifiers (NFC)

Identified with tidy-modernize-use-override.

[llvm] Remove redundaunt virtual specifiers (NFC)

Identified with modernize-use-override.

[IPO] Use std::array for AccessKind2Accesses (NFC)

Switching to std:array allow us to use fill.

While I am at it, this patch also converts one for loop to a
range-based one.

[Attributor][FIX] HasBeenWrittenTo logic should only be used for reads

If we look at a write, we should not enact the "has been written to"
logic introduced to avoid spurious write -> read dependenc

[Attributor][FIX] HasBeenWrittenTo logic should only be used for reads

If we look at a write, we should not enact the "has been written to"
logic introduced to avoid spurious write -> read dependences. Doing so
lead to elimination of stores we needed, which is obviously bad.

show more ...

[Attributor][FIX] Handle non-recursive but re-entrant functions properly

If a function is non-recursive we only performed intra-procedural
reasoning for reachability (via AA::isPotentiallyReachable)

[Attributor][FIX] Handle non-recursive but re-entrant functions properly

If a function is non-recursive we only performed intra-procedural
reasoning for reachability (via AA::isPotentiallyReachable). However,
if it is re-entrant that doesn't mean we can't reach. Instead of this
problematic logic in the reachability reasoning we utilize logic in
AAPointerInfo. If a location is for sure written by a function it can
be re-entrant or recursive we know only intra-procedural reasoning is
sufficient.

show more ...

[Attributor] Dominating must-write accesses allow unknown initial values

If we have a dominating must-write access we do not need to know the
initial value of some object to perform reasoning about

[Attributor] Dominating must-write accesses allow unknown initial values

If we have a dominating must-write access we do not need to know the
initial value of some object to perform reasoning about the potential
values. The dominating must-write has overwritten the initial value.

show more ...

[Attributor][NFC] Remove unnecessary overwritten methods

[Attributor] Use getFreedOperand() (NFC)

Track which operand is actually freed, to avoid the implicit
assumption that it is the first call argument.

[MemoryBuiltins] Add getFreedOperand() function (NFCI)

We currently assume in a number of places that free-like functions
free their first argument. This is true for all hardcoded free-like
function

[MemoryBuiltins] Add getFreedOperand() function (NFCI)

We currently assume in a number of places that free-like functions
free their first argument. This is true for all hardcoded free-like
functions, but with the new attribute-based design, the freed
argument is supposed to be indicated by the allocptr attribute.

To make sure we handle this correctly once allockind(free) is
respected, add a getFreedOperand() helper which returns the freed
argument, rather than just indicating whether the call frees *some*
argument.

This migrates most but not all users of isFreeCall() to the new
API. The remaining users are a bit more tricky.

show more ...

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an alloca

[MemoryBuiltins] Avoid isAllocationFn() call before checking removable alloc

Alloc directly checking whether a given call is a removable
allocation, instead of first checking whether it is an allocation
first.

show more ...

[Attributor] Deal with complex PHI nodes better during AAPointerInfo

We were quite conservative when it came to PHI node handling to avoid
recursive reasoning. Now we check more direct if we have se

[Attributor] Deal with complex PHI nodes better during AAPointerInfo

We were quite conservative when it came to PHI node handling to avoid
recursive reasoning. Now we check more direct if we have seen a PHI
already or not. This allows non-recursive PHI chains to be handled.

This also exposed a bug as we did only model the effect of one loop
traversal. `phi_no_store_3` has been adapted to show how we would have
used `undef` instead of `1` before. With this patch we don't replace
it at all, which is expected as we do not argue about loop iterations
(or alignments).

show more ...

Use value instead of getValue (NFC)

Use has_value instead of hasValue (NFC)

[Attributor] Teach checkForAllUses to follow returns into callers

If we can determine all call sites we can follow a use in a return
instruction into the caller. AAPointerInfo utilizes this feature.

[Attributor][NFC] Improve debug messages

[Attributor] Replace AAValueSimplify with AAPotentialValues

For the longest time we used `AAValueSimplify` and
`genericValueTraversal` to determine "potential values". This was
problematic for many

[Attributor] Replace AAValueSimplify with AAPotentialValues

For the longest time we used `AAValueSimplify` and
`genericValueTraversal` to determine "potential values". This was
problematic for many reasons:
- We recomputed the result a lot as there was no caching for the 9
locations calling `genericValueTraversal`.
- We added the idea of "intra" vs. "inter" procedural simplification
only as an afterthought. `genericValueTraversal` did offer an option
but `AAValueSimplify` did not. Thus, we might end up with "too much"
simplification in certain situations and then gave up on it.
- Because `genericValueTraversal` was not a real `AA` we ended up with
problems like the infinite recursion bug (#54981) as well as code
duplication.

This patch introduces `AAPotentialValues` and replaces the
`AAValueSimplify` uses with it. `genericValueTraversal` is folded into
`AAPotentialValues` as are the instruction simplifications performed in
`AAValueSimplify` before. We further distinguish "intra" and "inter"
procedural simplification now.

`AAValueSimplify` was not deleted as we haven't ported the
re-materialization of instructions yet. There are other differences over
the former handling, e.g., we may not fold trivially foldable
instructions right now, e.g., `add i32 1, 1` is not folded to `i32 2`
but if an operand would be simplified to `i32 1` we would fold it still.

We are also even more aware of function/SCC boundaries in CGSCC passes,
which is good even if some tests look like they regress.

Fixes: https://github.com/llvm/llvm-project/issues/54981

Note: A previous version was flawed and consequently reverted in
6555558a80589d1c5a1154b92cc3af9495f8f86c.

show more ...

[llvm] Use value instead of getValue (NFC)

[Attributor] Don't crash if getAnalysisResultForFunction() returns null LoopInfo

I have no idea what's going on here. This code was moved
around/introduced in change cb26b01d57f5 and starts crashing

[Attributor] Don't crash if getAnalysisResultForFunction() returns null LoopInfo

I have no idea what's going on here. This code was moved
around/introduced in change cb26b01d57f5 and starts crashing with a NULL
dereference once I apply https://reviews.llvm.org/D123090. I assume that
I've unwittingly taught the attributor enough that it's able to do more
clever things than in the past, and it's able to trip on this case. I
make no claims about the correctness of this patch, but it passes tests
and seems to fix all the crashes I've been seeing.

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

show more ...

Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"

This reverts commit f17639ea0cd30f52ac853ba2eb25518426cc3bb8 as three
AMDGPU tests haven't been updated. Will need to verify the

Revert "[Attributor] Replace AAValueSimplify with AAPotentialValues"

This reverts commit f17639ea0cd30f52ac853ba2eb25518426cc3bb8 as three
AMDGPU tests haven't been updated. Will need to verify the changes are
not regressions we should avoid.

show more ...

[Attributor] Replace AAValueSimplify with AAPotentialValues

For the longest time we used `AAValueSimplify` and
`genericValueTraversal` to determine "potential values". This was
problematic for many

[Attributor] Replace AAValueSimplify with AAPotentialValues

For the longest time we used `AAValueSimplify` and
`genericValueTraversal` to determine "potential values". This was
problematic for many reasons:
- We recomputed the result a lot as there was no caching for the 9
locations calling `genericValueTraversal`.
- We added the idea of "intra" vs. "inter" procedural simplification
only as an afterthought. `genericValueTraversal` did offer an option
but `AAValueSimplify` did not. Thus, we might end up with "too much"
simplification in certain situations and then gave up on it.
- Because `genericValueTraversal` was not a real `AA` we ended up with
problems like the infinite recursion bug (#54981) as well as code
duplication.

This patch introduces `AAPotentialValues` and replaces the
`AAValueSimplify` uses with it. `genericValueTraversal` is folded into
`AAPotentialValues` as are the instruction simplifications performed in
`AAValueSimplify` before. We further distinguish "intra" and "inter"
procedural simplification now.

`AAValueSimplify` was not deleted as we haven't ported the
re-materialization of instructions yet. There are other differences over
the former handling, e.g., we may not fold trivially foldable
instructions right now, e.g., `add i32 1, 1` is not folded to `i32 2`
but if an operand would be simplified to `i32 1` we would fold it still.

We are also even more aware of function/SCC boundaries in CGSCC passes,
which is good even if some tests look like they regress.

Fixes: https://github.com/llvm/llvm-project/issues/54981

Note: A previous version was flawed and consequently reverted in
6555558a80589d1c5a1154b92cc3af9495f8f86c.

show more ...

[Attributor] Make heap2stack record alloca placement

We recently learned to place the alloca during the heap2stack
transformation in the entry block but we did not account for other
concurrent modif

[Attributor] Make heap2stack record alloca placement

We recently learned to place the alloca during the heap2stack
transformation in the entry block but we did not account for other
concurrent modifications. We need to record our decision rather than
checking (then outdated) passes during the manifest stage. This will
also allow us to use a custom (=optimistic) "loop info" in the future.

show more ...

[Attributor][NFC] Improve heap2stack result readability and code style

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() m

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() method and its usages.

show more ...

[Attributor] Move heap2stack allocas to the entry block if possible

If we are certainly not in a loop we can directly emit the heap2stack
allocas in the function entry block. This will help to get r

[Attributor] Move heap2stack allocas to the entry block if possible

If we are certainly not in a loop we can directly emit the heap2stack
allocas in the function entry block. This will help to get rid of them
(SROA) and avoid stacksave/restore intrinsics when the function is
inlined.

show more ...