[PATCH] D104547: [langref] attempt to clarify semantics of inttoptr/ptrtoint for non-integral types

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev added a comment.

The more I think of it, the more unclear the attempt to prohibit insertion of new casts becomes. I understand the goal, but the wording here leaves too many room for false interpretations.

I believe that what you really wanted to say is that the result of any cast may change whenever the external state changes, and therefore we should not introduce new uses from casts from potential other states into where was uses of different state.

Simple example of (meaningless and merciless) demon optimization.

Old code:

  %x = ptrtoint a, b

New code:

  %i1 = ptrtoint a,b
  %i2 = ptrtoint a,b
  %x = select undef, %i1, %i2

We have introduced new dynamically executed cast. We have not introduced new dynamically used value. The transform looks meaningless, but should be absolutely legal from perspectice that casts are state-dependent.

It might not be illegal if we did something like

  %i1 = ptrtoint a,b
  <fence>
  %i2 = ptrtoint a,b
  %x = select undef, %i1, %i2

In this case, at the point of <fence> the outer state may change, and therefor `%x` may be a value from either one or another state, which assumes different cast results.

I think we should not have statements like "inserting cast instructions is illegal", no matter what "illegal" means. We should instead clearly state that if the uses of casts with one state in place where state might have changed is undef.


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

https://reviews.llvm.org/D104547