[PATCH] D79454: [IR] `byval` arguments cause reads at call sites
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 6 11:54:37 PDT 2020
jdoerfert added a comment.
In D79454#2023176 <https://reviews.llvm.org/D79454#2023176>, @hfinkel wrote:
> That all having been said, if we have a situation where a byval argument is never accessed, perhaps we really want the optimizer to just remove the byval attribute?
While we can and should do that, I would really like it to be representable without requiring transformtions.
I also fear there might be non-trivial corner cases just waiting to be explored.
---
I doubt the following is possible but maybe the idea becomes clear:
// optnone to simulate complicated arithmetic we do not fold (int2ptr, etc)
__attribute__((noinline,optnone))
static int make_the_compiler_complicated(struct S s, int o, int p) {
return &s.arr[o] == &s.arr[p];
}
int caller(int o, int p) {
int r = 0;
struct S *s = new S;
r = make_the_compiler_complicated(*s, o, p);
delete s;
return r;
}
We do not access `s` but it is not trival to remove the uses of `s`. Eventually we want code motion to move the geps and comparison out of the function but for now we cannot.
If we remove the `byval` we have a `readnone` function we can move after the delete, I think, which would cause poison in the result (due to the `inbounds` gep). Now that I wrote this I am concerned we already have this problem without `byval` :(
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79454/new/
https://reviews.llvm.org/D79454
More information about the llvm-commits
mailing list