[clang] [llvm] [Inliner] Propagate more attributes to params when inlining (PR #91101)
via llvm-commits
llvm-commits at lists.llvm.org
Fri Jul 5 22:30:11 PDT 2024
goldsteinn wrote:
> High level question: Are all of these really useful?
>
> For parameter attributes, there are really two types, ones that are used to reason about calls, and ones used to reason about function definitions. I think the split here is something like:
>
> * readonly/readnone: Mostly used for calls. Since recently used for definitions in conjunction with noalias.
> * writeonly: Used for calls.
> * range, dereferenceable_or_null: Used for definitions.
> * align: Mostly used for definitions, but also used for intrinsic calls.
> * nonnull, dereferenceable: Mostly used for definitions. Used for calls in conjunction with noundef for "dominating conditions" in isKnownNonZero.
>
> Based on that breakdown, I can see some usefulness for propagating the readonly family, align and nonnull/dereferenceable.
>
> Is there anything that propagating range and dereferenceof_or_null is good for? I haven't checked how the latter is used in detail, but I'm pretty confident that we don't use call-site parameter range information for anything.
I see this a little differently. As a general principal, I think we should be doing our best to make our transforms preserve as much information as possible. It seems fine to drop something like `nofree` that isn't entirely well-defined, because we don't actually know what we are preserving yet, but something like `dereferenceable_or_null` is well defined and its not a great stretch of the imagination that the information may be useful somewhere in LLVM or in a downstream project.
On the point of `dereferenceable_or_null`, I'd say if `dereferenceable` is considered useful, `dereferenceable_or_null` is also useful by, at the very least, its a potential `dereferenceable` if at any point in the future we can prove the pointer is non-null (and it's hard to argue we have ruled this out by now as inlining generally opens up a lot of new analysis).
https://github.com/llvm/llvm-project/pull/91101
More information about the llvm-commits
mailing list