[llvm-dev] [InstCombine] addrspacecast assumed associative with gep

via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 10 18:43:00 PDT 2019


The following combine(-enabling transformation) makes me
uncomfortable:
  gep(addrspacecast(gep p0) to p1)
  addrspacecast(gep(gep p0)) to p1
It's applied at visitAddrSpaceCast in InstCombineCasts.cpp.
Before this, I'd always assumed address spaces were very much "user
domain". Datalayout even supports marking a space as "non-integral",
to designate that manipulation as bits is impossible. In my case, I
have a different byte width in p1 over p0 (I know - but we all knew it
was coming). All of p0 can be addressed in p1, but the reverse
transformation is only sometimes possible as GEPs behave differently
on the other side of the cast. This transformation of course breaks
that.
By my reading of ISO 18037:2006(E), it is required that if one address
in p0 can be cast to p1, they all can, but I cannot find any
requirements placed on the reverse operation - and further, this is a
C standard, not a low-level machine.
I realise this may be seen as an abuse of mechanics, but is it really
intended that addrspacecast and geps can be rearranged in all
circumstances, in all address space combinations? To me, the fewer
assumptions made about addrspaces the better - callbacks should be
used before optimising past them.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/fe82b500/attachment-0001.html>


More information about the llvm-dev mailing list