[PATCH] D75817: [NVPTX] Fix instruction selection for addresses in case of addrspacecasts

Artem Belevich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 9 10:46:51 PDT 2020


tra requested changes to this revision.
tra added a comment.
This revision now requires changes to proceed.

While such reordering may be beneficial, in general, `GEP(ASC(x))` is not always equivalent of `ASC(GEP(x))`, so we can't just blindly do it. I believe this has been discussed few times in the past, though I can't find relevant emails now.

According to PTX spec for `cvta` instruction which we use for ASC, `resulting address is undefined in cases where the generic address does not fall within the address window of the specified state space`.
So, if `x` points to the last element of the target address space, and GEP adds non-zero offset, then behavior of GEP(ASC(x)) will be defined, but ASC(GEP(x)) will be not.

There may also be other interesting issues on the boundaries of address spaces. I.e. if AS10 and AS11 are adjacent in generic address space and x, again, points at AS10's last element in generic AS, then GET(ASC(x)) will result in out-of-bounds access in AS10, but ASC(GEP(x)) will point to a valid address in AS11. AFAICT, PTX does not give any guarantees regarding generic address space layout, so we can't rule out this case as we don't have a way to check the bounds.
Similar issues will affect specific-to-generic ASC, too. E.g. GEP(ASC(x) from AS10 to generic) will give us a valid generic pointer, while ASC(GEP(x)) will be undefined.

Another point is that if this optimization is worth doing (assuming we can figure out how to do it safely), then doing it in IR, instead of pattern-matching it during lowering may be a better way. We already have https://llvm.org/doxygen/SeparateConstOffsetFromGEP_8cpp_source.html which does similar optimization, though it does not handle `addrspacecast` at the moment.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75817/new/

https://reviews.llvm.org/D75817





More information about the llvm-commits mailing list