[all-commits] [llvm/llvm-project] 94c1a8: [DSE] Don't use initializes on byval argument (#12...
Nikita Popov via All-commits
all-commits at lists.llvm.org
Tue Feb 11 14:13:31 PST 2025
Branch: refs/heads/release/20.x
Home: https://github.com/llvm/llvm-project
Commit: 94c1a8ea1bfea3cbd7191783c85b2cead642f653
https://github.com/llvm/llvm-project/commit/94c1a8ea1bfea3cbd7191783c85b2cead642f653
Author: Nikita Popov <npopov at redhat.com>
Date: 2025-02-11 (Tue, 11 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.
(cherry picked from commit 2d31a12dbe2339d20844ede70cbb54dbaf4ceea9)
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list