I just learned of P2815, and I do not know of another place I can respond
to it, so I'm going to answer here.

In my opinion, the proposal in question eliminates all provenance based
alias analysis, used to eliminate memory accesses when unanalyzed code is
present.

Consider the following example code:

int foo(int* p){
     int i;
     opaque_operation(&i,p);
     i = 0;
     *p = 1;
     return i;
}

(Where the optimizer is unable to analyze `opaque_operation`
In current compilers, this can be optimized to calling `opaque_operation`,
writing `1` to `p`, and then returning `0`. Under the proposal, however,
`opaque_operation` could observe that `&i` and `p` have the same *value
representation*, which means that they must be equal (it may do so with
defined behaviour in all executions, for example, by terminating if they
are bytewise unequal). Thus the write to `p` may modify the value of `i`.
This would make the transformation to:

int foo(int* p){
    opaque_operation(&[rsp],p);
    *p = 1;
    return 0;
}

invalid under the proposal.

In my opinion, this extends to basically all similar transformations, which
is the majority of provenance-based alias analysis.

Further, it means that a non-volatile read as a character type (which may
then be used to test the value representation) cannot be optimized away
when applied to an unknown object (because that object may contain a
pointer). In particular, a discarded `memcmp` is now able to alter the
behaviour of the program, despite previously being able to be elided
because the function is pure.

Link to the proposal in question:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2815r0.pdf.