[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