[all-commits] [llvm/llvm-project] 2d31a1: [DSE] Don't use initializes on byval argument (#12...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2d31a12dbe2339d20844ede70cbb54dbaf4ceea9
      https://github.com/llvm/llvm-project/commit/2d31a12dbe2339d20844ede70cbb54dbaf4ceea9
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2025-02-10 (Mon, 10 Feb 2025)

  Changed paths:
    M llvm/docs/LangRef.rst
    M llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
    M llvm/test/Transforms/DeadStoreElimination/inter-procedural.ll

  Log Message:
  -----------
  [DSE] Don't use initializes on byval argument (#126259)

There are two ways we can fix this problem, depending on how the
semantics of byval and initializes should interact:

* Don't infer initializes on byval arguments. initializes on byval
refers to the original caller memory (or having both attributes is made
a verifier error).
* Infer initializes on byval, but don't use it in DSE. initializes on
byval refers to the callee copy. This matches the semantics of readonly
on byval. This is slightly more powerful, for example, we could do a
backend optimization where byval + initializes will allocate the full
size of byval on the stack but not copy over the parts covered by
initializes.

I went with the second variant here, skipping byval + initializes in DSE
(FunctionAttrs already doesn't propagate initializes past byval). I'm
open to going in the other direction though.

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



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications