[FunctionAttrs] Improve handling of alias-preserving intrinsic calls (#68453)

Fixes #68270

The function attribute analysis handles many instructions, like
addrspacecast, which do not themselves

[FunctionAttrs] Improve handling of alias-preserving intrinsic calls (#68453)

Fixes #68270

The function attribute analysis handles many instructions, like
addrspacecast, which do not themselves read or write memory but which
transform pointers into other values in the same alias set.

There are intrinsic functions, such as ptrmask or the AMDGPU-specific
make.buffer.rsrc, which also preserve membership in alias sets without
capturing. This commit adds the addrspacecast-like behavior to these
calls.

show more ...

[FunctionAttrs] Only check ArgMem effects when inferring argument attrs (#69571)

When inferring readonly/writeonly on arguments, if the argument is
passed to a call, we should only check the ArgMem

[FunctionAttrs] Only check ArgMem effects when inferring argument attrs (#69571)

When inferring readonly/writeonly on arguments, if the argument is
passed to a call, we should only check the ArgMem effects implied by the
call -- we don't care whether the call reads/writes non-arg memory
(captured pointers are not relevant here, because they will abort the
analysis entirely).

This also fixes a regression that was introduced when moving to
MemoryEffects: The code was still checking the old WriteOnly attribute
on functions, which no longer exists.

show more ...

[FunctionAttrs] Consider recursive argmem effects (PR63936)

When inspecting the function body, we can't simply ignore effects
of functions in the SCC entirely, because an argmem access of a
recursiv

[FunctionAttrs] Consider recursive argmem effects (PR63936)

When inspecting the function body, we can't simply ignore effects
of functions in the SCC entirely, because an argmem access of a
recursive call might result in an access to another location in
the callee.

Fix this by separately tracking memory effects that would occur if
the SCC accesses argmem, and then later add those.

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

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

show more ...

[FunctionAttrs] Extract some code into separate functions (NFC)

To reduce diff in a future patch.

[FunctionAttrs] Unconditionally perform argument attribute inference in the first function-attrs pass

Summary:
Argument attributes like NoAlias and ReadOnly could affect memoryssa and thus earlyCS

[FunctionAttrs] Unconditionally perform argument attribute inference in the first function-attrs pass

Summary:
Argument attributes like NoAlias and ReadOnly could affect memoryssa and thus earlyCSE in the function simplification pipeline.
https://reviews.llvm.org/D145210 adjusted PostOrderFunctionAttrs placement and caused the argument attributes not referred for the use
in the pipeline. This work (initiated by @nikic) unconditionally performs argument attribute inference in the first function-attrs pass.

Reviewers:
aeubanks and nikic

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

show more ...

[MemoryEffects][NFCI] Make the MemoryEffects class reusable

In a follow up we will reuse the logic in MemoryEffectsBase to merge
AAMemoryLocation and AAMemoryBehavior without duplicating all the bit

[MemoryEffects][NFCI] Make the MemoryEffects class reusable

In a follow up we will reuse the logic in MemoryEffectsBase to merge
AAMemoryLocation and AAMemoryBehavior without duplicating all the bit
fiddling code already available in MemoryEffectsBase.

Reviewed By: nikic

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

show more ...

[FunctionAttrs] Remove errant whitespace; NFC

Revert "[FunctionAttrs] Propagate some func/arg/ret attributes from caller to callsite (WIP)"

Accidental commit/push!

This reverts commit 4fa971ff62c3c48c606b792c572c03bd4d5906ee.

[FunctionAttrs] Propagate some func/arg/ret attributes from caller to callsite (WIP)

This is the consolidation of D151644 and D151943 moved from
InstCombine to FunctionAttrs. This is based on discus

[FunctionAttrs] Propagate some func/arg/ret attributes from caller to callsite (WIP)

This is the consolidation of D151644 and D151943 moved from
InstCombine to FunctionAttrs. This is based on discussion in the above
patches as well as D152081 (Attributor). This patch was written in a
way so it can have an immediate impact in currently active passes
(FunctionAttrs), but should be easy to port elsewhere (Attributor or
Inliner) if that makes more sense later on.

Some function attributes imply the attribute for all/some instructions
in the function. These attributes can be safely propagated to
callsites within the function that are missing the attribute. This can
be useful when 1) analyzing individual instructions in a function
and 2) if the original caller is later inlined, as if the attributes are
not propagated, they will be lost.

This patch implements propagation in a new class/file
`InferCallsiteAttrs` which can hypothetically be included elsewhere.

At the moment this patch infers the following:

Function Attributes:
- mustprogress
- nofree
- willreturn
- All memory attributes (readnone, readonly, writeonly, argmem,
etc...)
- The memory attributes are only propagated IFF the set of
pointers available to the callsite is the same as the set
available outside the caller (i.e no local memory arguments
from alloca or local malloc like functions).

Argument Attributes:
- noundef
- nonnull
- nofree
- readnone
- readonly
- writeonly
- nocapture
- nocapture is only propagated IFF the set of pointers
available to the callsite is the same as the set available
outside the caller and its guranteed that between the
callsite and function return, the state of any capture
pointers will not change (so the nocaptured gurantee of the
caller has been met by the instruction preceding the
callsite and will not changed).

Argument are only propagated to callsite arguments that are also function
arguments, but not derived values.

Return Attributes:
- noundef
- nonnull

Return attributes are only propagated if the callsite's return value
is used as the caller's return and execution is guranteed to pass from
callsite to return.

The compile time hit of this for -O3 and -O3+thinLTO is ~[.02, .37]%
regression. Proper LTO, however, has more significant regressions (up
to 3.92%):
https://llvm-compile-time-tracker.com/compare.php?from=94407e1bba9807193afde61c56b6125c0fc0b1d1&to=79feb6e78b818e33ec69abdc58c5f713d691554f&stat=instructions:u

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

show more ...

Remove several no longer needed includes. NFCI

Mostly removing includes of InitializePasses.h and Pass.h in
passes that no longer has support for the legacy PM.

[FunctionAttrs] Fix nounwind inference for landingpads

Currently, FunctionAttrs treats landingpads as non-throwing, and
will infer nounwind for functions with landingpads (assuming they
can't unwind

[FunctionAttrs] Fix nounwind inference for landingpads

Currently, FunctionAttrs treats landingpads as non-throwing, and
will infer nounwind for functions with landingpads (assuming they
can't unwind in some other way, e.g. via resum). There are two
problems with this:

* Non-cleanup landingpads with catch/filter clauses do not
necessarily catch all exceptions. Unless there are catch ptr null
or filter [0 x ptr] zeroinitializer clauses, we should assume
that we may unwind past this landingpad. This seems like an
outright bug.
* Cleanup landingpads are skipped during phase one unwinding, so
we effectively need to support unwinding past them. Marking these
nounwind is technically correct, but not compatible with how
unwinding works in reality.

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

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

show more ...

[Pipeline] Adjust PostOrderFunctionAttrs placement in simplification pipeline

We can infer more attribute information once functions are fully
simplified, so move the PostOrderFunctionAttrs pass aft

[Pipeline] Adjust PostOrderFunctionAttrs placement in simplification pipeline

We can infer more attribute information once functions are fully
simplified, so move the PostOrderFunctionAttrs pass after the function
simplification pipeline. However, just doing this can impact
simplification of recursive functions since function simplification
takes advantage of function attributes of callees (some LLVM tests are
actually impacted by this), so keep a copy of PostOrderFunctionAttrs
before the function simplification pipeline that only runs on recursive
functions.

For example, this fixes the small regression noticed in https://reviews.llvm.org/D128830.

This requires some restructuring of the CGSCC NoRerun feature. We need
to cache the ShouldNotRunFunctionPassesAnalysis analysis after the
simplification is done, which now is after the second
PostOrderFunctionAttrs run, rather than after the function
simplification pipeline.

Compile time impact:
https://llvm-compile-time-tracker.com/compare.php?from=33cf40122279342b50f92a3a53f5c185390b6018&to=1bb2a07875634e508a6bdf2ca1b130f55510f060&stat=instructions:u

Compile time increase from unconditionally running the first PostOrderFunctionAttrs:
https://llvm-compile-time-tracker.com/compare.php?from=1bb2a07875634e508a6bdf2ca1b130f55510f060&to=f4f87e89cc7a35c64e3a103a8036192a84ae002b&stat=instructions:u

Reviewed By: nikic

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

show more ...

[IPO] Remove various legacy passes

These are part of the optimization pipeline, of which the legacy pass manager version is deprecated and being removed.

[FunctionAttrs] Move nosync inference into inferAttrsFromFunctionBodies() (NFC)

There doesn't appear to be any reason why this attribute is
inferred separately from other ones that use AttributeInfe

[FunctionAttrs] Move nosync inference into inferAttrsFromFunctionBodies() (NFC)

There doesn't appear to be any reason why this attribute is
inferred separately from other ones that use AttributeInferer.

show more ...

[FunctionAttrs] Slightly clean up returned attr inference (NFC)

Use hasAttrSomewhere() and directly return Argument from the
helper.

[RPOFunctionAttrs] Use LazyCallGraph instead of CallGraph

There are a few more uses of CallGraph that should be replaced with LazyCallGraph

Also delete legacy version of RPOFunctionAttrs since it i

[RPOFunctionAttrs] Use LazyCallGraph instead of CallGraph

There are a few more uses of CallGraph that should be replaced with LazyCallGraph

Also delete legacy version of RPOFunctionAttrs since it is deprecated and LazyCallGraph is not available under the legacy pass manager.

Reviewed By: aeubanks

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

show more ...

MemoryLocation: convert Optional to std::optional

[IR] Switch everything to use memory attribute

This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemo

[IR] Switch everything to use memory attribute

This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.

The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.

High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.

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

show more ...

[AliasAnalysis] Introduce getModRefInfoMask() as a generalization of pointsToConstantMemory().

The pointsToConstantMemory() method returns true only if the memory pointed to
by the memory location i

[AliasAnalysis] Introduce getModRefInfoMask() as a generalization of pointsToConstantMemory().

The pointsToConstantMemory() method returns true only if the memory pointed to
by the memory location is globally invariant. However, the LLVM memory model
also has the semantic notion of *locally-invariant*: memory that is known to be
invariant for the life of the SSA value representing that pointer. The most
common example of this is a pointer argument that is marked readonly noalias,
which the Rust compiler frequently emits.

It'd be desirable for LLVM to treat locally-invariant memory the same way as
globally-invariant memory when it's safe to do so. This patch implements that,
by introducing the concept of a *ModRefInfo mask*. A ModRefInfo mask is a bound
on the Mod/Ref behavior of an instruction that writes to a memory location,
based on the knowledge that the memory is globally-constant memory (in which
case the mask is NoModRef) or locally-constant memory (in which case the mask
is Ref). ModRefInfo values for an instruction can be combined with the
ModRefInfo mask by simply using the & operator. Where appropriate, this patch
has modified uses of pointsToConstantMemory() to instead examine the mask.

The most notable optimization change I noticed with this patch is that now
redundant loads from readonly noalias pointers can be eliminated across calls,
even when the pointer is captured. Internally, before this patch,
AliasAnalysis was assigning Ref to reads from constant memory; now AA can
assign NoModRef, which is a tighter bound.

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

show more ...

Reapply [FunctionAttrs] Make location classification more precise

Reapplying after the fix for volatile modelling in D135863.

-----

Don't add argmem if the pointer is clearly not an argument (e.g.

Reapply [FunctionAttrs] Make location classification more precise

Reapplying after the fix for volatile modelling in D135863.

-----

Don't add argmem if the pointer is clearly not an argument (e.g.
a global). I don't think this makes a difference right now, but
gives more obvious results with D135780.

show more ...

[FuncAttrs] Extract code for adding a location access (NFC)

This code is the same for accesses from call arguments and for
accesses from other (single-location) instructions. Extract i
into a common

[FuncAttrs] Extract code for adding a location access (NFC)

This code is the same for accesses from call arguments and for
accesses from other (single-location) instructions. Extract i
into a common function.

show more ...

[FunctionAttrs] Volatile operations can access inaccessible memory

Per LangRef, volatile operations are allowed to access the location
of their pointer argument, plus inaccessible memory:

> Any vol

[FunctionAttrs] Volatile operations can access inaccessible memory

Per LangRef, volatile operations are allowed to access the location
of their pointer argument, plus inaccessible memory:

> Any volatile operation can have side effects, and any volatile
> operation can read and/or modify state which is not accessible
> via a regular load or store in this module.
> [...]
> The allowed side-effects for volatile accesses are limited. If
> a non-volatile store to a given address would be legal, a volatile
> operation may modify the memory at that address. A volatile
> operation may not modify any other memory accessible by the
> module being compiled. A volatile operation may not call any
> code in the current module.

FunctionAttrs currently does not model this and ends up marking
functions with volatile accesses on arguments as argmemonly,
even though they should be inaccessiblemem_or_argmemonly.

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

show more ...

[AA] Rename getModRefBehavior() to getMemoryEffects() (NFC)

Follow up on D135962, renaming the method name to match the new
type name.

[AA] Rename uses of FunctionModRefBehavior (NFC)

Followup to D135962 to rename remaining uses of
FunctionModRefBehavior to MemoryEffects. Does not touch API names
yet, but also updates variables nam

[AA] Rename uses of FunctionModRefBehavior (NFC)

Followup to D135962 to rename remaining uses of
FunctionModRefBehavior to MemoryEffects. Does not touch API names
yet, but also updates variables names FMRB/MRB to ME, to match the
new type name.

show more ...

Revert "[FunctionAttrs] Make location classification more precise"

This reverts commit b05f5b90a12098660a4fc16da0b4d421ddfe14e2.

There are thread sanitizer buildbot failures in simple_stack.c.
I th

Revert "[FunctionAttrs] Make location classification more precise"

This reverts commit b05f5b90a12098660a4fc16da0b4d421ddfe14e2.

There are thread sanitizer buildbot failures in simple_stack.c.
I think that's because this ended up affecting the handling of
volatile accesses to allocas. Reverting for now.

show more ...