[llvm] [Inliner] Propagate callee argument memory access attributes before inlining (PR #89024)

[via llvm-commits]

goldsteinn wrote:

> > The change looks correct to me, but I wonder where this is useful and what the benefit/compile-time tradeoff is?
> > Propagating these attributes from the function definition itself to its body could and maybe should happen elsewhere: once per definition instead of each time the inliner runs. And what's the scenario in which the attributes are added on the `call` instruction itself?
> 
> Well we are trying to progagate the callsite attributes which can differ from the function attributes (although access attributes are rare). By having in the inliner we only propagate at the point we may lose the information.
> 
> > I assume there's some reason, otherwise you wouldn't have posted this PR, but I'd still like to understand it better because it isn't obvious to me.
> 
> The motivation for me is so that you can put attributes on wrapper functions that will be inlined. The primary attribute in my case is `nocapture`, but the conditions for that are trickier so just went with read/write attributes for now.

A bit more clearly there are two cases:
1) The user sometimes gives us attributes on wrapper functions which are lost during inlining.
2) We sometimes have callsite specific attributes that are lost during inlining.


https://github.com/llvm/llvm-project/pull/89024