We can improve our deduction if we stop at PHI and select instructions
and also iterate the returned values explicitly. The latter helps with
isImpliedByIR deductions.
The following pattern fails on recent GCC versions with -std=c++20 flag passed
and succeeds with -std=c++17. Such behavior is not observed on Clang 16.0.
```c++
template <typename T>
struct Foo {
Foo<T>(int a) {}
};
```
This patch removes template parameter from constructor in two occurences to
make the following command complete successfully:
bazel build -c fastbuild --cxxopt=-std=c++20 --host_cxxopt=-std=c++20 @llvm-project//llvm/...
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D154782
The very first AA, at least the first one in order, is not necessary
anymore. `AAReturnedValues` was from a different time; one might say, a
simpler time.
It was rewriten once to use `Attribute::getAssumedSimplifiedValues`,
which is what the replacement, `AAPotentialValuesReturned`, does too.
To match the old behavior we needed to avoid the helper
`AAReturnedFromReturnedValues` and iterate the return instructions
explicitly, however, it is still less complexity than it was before.
`AAReturnedFromReturnedValues` and `getAssumedSimplifiedValues` now
allow users to stop at PHI and select nodes or to ignore those and look
through. `AANoFPClass` will stop at select and phi nodes to read the
fast math flags.
Fixes: https://github.com/llvm/llvm-project/issues/63404
Differential Revision: https://reviews.llvm.org/D154917
This patch adds initial support for the `AAAddressSpace` abstract
attributor interface to deduce and query address space information for a
pointer. We simply query the underlying objects that a pointer can point
to and find a common address space if they exist. This is the minimal
support for the interface, we currently manifest changes on loads and
stores. Additionally we should use the target transform information to
deduce if an address space transformation is a no-op for the target
machine when calculating compatibility.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D120586
AANoCapture is now the first non-boolean AA that is always queried via
the new APIs and not created manually.
We explicitly do not manifest nocapture for `null` and `undef` anymore.
AANonNull is now the first AA that is always queried via the new APIs
and not created manually. Others will follow shortly to avoid trivial
AAs whenever possible.
This commit introduced some helper logic that will make it simpler to
port the next one. It also untangles AADereferenceable and AANonNull
such that the former does not keep a handle on the latter. Finally,
we stop deducing `nonnull` for `undef`, which was incorrect.
Before, we checked and manifested attributes right in the IR. This was
bad as we modified the IR before the manifest stage. Now we can
add/remove/inspect attributes w/o going to the IR (except for the
initial query).
We had some custom manifest for assumption attributes but we use the
generic manifest logic. If we later decide to curb duplication (of
attributes on the call site and callee), we can do that at a single
location and for all attributes.
The test changes basically add known `llvm.assume` callee information to
the call sites.
We had some custom handling for existing MemoryEffects but we now move
it to the place we check other existing attributes before we manifest
new ones. If we later decide to curb duplication (of attributes on the
call site and callee), we can do that at a single location and for all
attributes.
The test changes basically add known `memory` callee information to the
call sites.
With the helpers in place to judge AAs [1] we can remove the custom
rolled initialization checking code. This exposed a minor oversight in
the AAMemoryLocation where we did not check the IR before we gave up for
a declaration.
[1] d33bca840a
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
We now consistently use `CallBase::getCalledOperand` rather than
`getCalledFunction`, as we do not want the type checked performed by the
latter. This exposed various missing checks to handle mismatches
properly, but it is good to have them explicit now.
In a follow up we might want to flag certain calls as UB, but for now,
we allow everything to cut down on unexpected differences.
Instead of creating an AA for an IR attribute we can first check if it
is implied/known. If so, we can save the time to create the AA, figure
out it is implied, fix it, and later manifest it in the IR
(redundantly). Other IR attributes can be added to the list in
`AA::hasAssumedIRAttr` later on, for now we support 8 different ones.
For a lightweight pass we do not want to instantiate or use the
MustBeExecutedContextExplorer. This simply allows such a configuration.
While at it, the explorer is now allocated with the bump allocator.
If we had an unknown access but already some prior knowledge (known), we
could have ended up ignoring the unknown access all together. The
problem is that we track unknown not as all locations but separately.
This patch bridges the gap and expands the unknown bits to "all bits"
when we add an access.
Fixes: https://github.com/llvm/llvm-project/issues/63291
The logic and implementation follows the removal of no-op barriers. If
the fence is not making updates visible, either to the world or the
current thread, it is not needed. Said differently, the fences we remove
do not establish synchronization (happens-before) edges.
This allows us to eliminate some of the regression caused by:
https://reviews.llvm.org/D145290
Derive the mustprogress attribute based on the willreturn attribute
or the fact that all callers are mustprogress.
Differential Revision: https://reviews.llvm.org/D94740
AS(4), when targeting GPUs, is constant. Accesses to constant memory are
(historically) not treated as "memory accesses", hence we should deduce
`memory(none)` for those.
