Fixes PR#52062 and one of the remaining cases of PR#47644.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/Transforms/DeadStoreElimination/memset-and-strncpy.ll | ||
---|---|---|
2 ↗ | (On Diff #387760) | Tests for passes should only test that particular pass, not the whole optimization pipeline. |
llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp | ||
---|---|---|
216 | Same here |
Is there a way to add the right attributes to strncpy to avoid needing to special case it in DSE?
llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp | ||
---|---|---|
223 | Are we missing a return MemoryLocation::getAfter(CB->getArgOperand(0)) here to preserve the existing behavior if *CB is not a libfunc (or not available)? | |
1372 | having this logic here makes the code harder to read. Can this be moved to isReadClobber? Or into BasicAAResult::getModRefInfo directly? |
It would be great to somehow connect write_only/read_only with size arg but I dont think this is possible now. GCC’s access attribute is more poweful and it can be used in this way.
Maybe good idea for GSoC?
Yeah, but I was actually thinking about the special handling for isReadClobber (see inline comments). I don't think the special handling there is needed, because should strncpy already have the required attributes to determine it is not a read clobber.
llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp | ||
---|---|---|
1372 | Actually this should not be needed, because strncpy already *has* the correct attributes (first arg write only, second arg readonly and function argmemonly), right? |
llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp | ||
---|---|---|
1372 | According to BuildLibCalls, yes, right. |
Thanks for the latest updates!
We already have tests with other library calls in llvm/test/Transforms/DeadStoreElimination/libcalls.ll. It might good to move the tests from llvm/test/Transforms/DeadStoreElimination/memset-and-strncpy.ll to that file and recommit the changes.
Are you planning on also adding support for other *n* variants of library calls?
@fhahn Fixed and rebased, thanks for the review! (And I'll need someone to commit this for me. You can use name and email as in commit 6259016361345e09f0607ef4e037e00bcbe4bd40 for attribution. Thanks!)
Are you planning on also adding support for other *n* variants of library calls?
Which ones are you thinking of in particular? strncpy is the "easy" one because it always writes exactly n bytes, but I can have a look at some others as well.
I committed the tests separately in ffe1741b5ccab07cbf45fe99033e4119688eb5a5. Could you rebase the patch on top of that change?
Same here