[PATCH] D104498: [WIP][ScalarEvolution] Strictly enforce pointer/int type rules.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

I'm not sure I understand what the difference would be between `ptrtoint(a) - ptrtoint(b)` and `ptrsubtract(a, b)` would be.  I guess the idea is that ptrsubtract() would somehow be allowed with non-integral pointers, where ptrtoint wouldn't be legal?  So the question is whether we can get away without adding ptrsubtract(), without significantly regressing non-integral pointer handling?

There are some number of places which actually only care whether the difference between two pointers is a constant.  We actually have a dedicated method computeConstantDifference() for that, but it's currently weaker than just writing `isa<SCEVConstant>(SE.getMinusSCEV(a, b))` or whatever.  I experimented with fixing that, but I think we'd need a completely different implementation strategy.

We could improve computeConstantDifference(), and use it various places to reduce the number of places that want a real pointer diff.  Along those lines, there are also a few places that want to compute a constant range for the distance between two pointers; we could also add a method for that.

There are also places that either statically know the two SCEVs they're subtracting have the same pointer base, or don't care about the result if the pointer bases are different; we could add a method for that.

If we had all that, I'm not sure we would need the full-power getPointerDiff() anywhere. At least, looking over my patch, all the cases this patch uses getPointerDiff would be covered, I think, except maybe LSR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104498