Hi,

Thanks for forwarding the email to me Arthur.

On Tue, Feb 21, 2023 at 9:53 PM connor horman via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

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.

The presentation's title slide (and unfortunately nowhere else — I missed it the first time too!) refers to P2188:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2188r1.html

which, being a WG21 paper, contains contact info for the author. I've cc'ed him here.

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

These were the slides of the presentation I did for EWG. They are in the mailing as a record; as the title suggests, this is a presentation of the paper that Arthur linked to. As for most presentations, there were a lot of things I said that are not on the slides.

Also, as Thiago points out, this is my opinion, not an accepted proposal or statement by the committee as a whole.

The fundamental point of the paper, and thus the presentation, is that the standard is inconsistent. The paper and presentation present a series of things that are true about trivially copyable types, by the wording of the standard. The problem is that the standard then says that (a) pointers are trivially copyable types, and (b) some of these properties don't apply to them.

We need to fix it. Ideally in a way that (a) doesn't break too much preexisting code that relies on these properties applying to pointers (and there is a lot that has been written over the years, and is currently in production, working just fine), and (b) doesn't rule out too many optimization techniques and opportunities.

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 [...

 

int foo(int *p) {

    int i; opaque_operation(&i, p);

    *p = 1; return 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 [...] invalid under the proposal.

This isn't a proposal (yet), it's my interpretation of current words in the standard. If you agree with my analysis, and the conclusion that this rules out optimizations, *they have always been ruled out*, and any compiler that did them would always have been non-conforming.

If you disagree with my interpretation, I would love to see specific references to where my logic is wrong, and/or how you would fix the inconsistency.

Anyway, in this case, the optimization cannot be permitted if &i could have the same bytes as the value passed as p. It would be easy for the compiler to check that prior to calling opaque_operation, but that would change the codegen.

So I don't think you're correct to worry that P2188 / P2815 would completely destroy all provenance-based optimizations. It needs to propose some wording before we can say anything concrete about it, of course. And it might end up destroying some optimizations. But it needn't destroy all of them. And at first glance it doesn't seem out-of-keeping with the direction of C++.

(Likewise, the existence of `reinterpret_cast` doesn't destroy all type-based alias analysis. And `const_cast` famously destroys some-but-not-all const-based optimizations.)

Here I agree with Arthur. If people agree with my conclusions, then some provenance-based optimizations are ruled out. Not all of them, but maybe a lot. That's a price I'm willing to pay for the knowledge that the language is self-consistent in what it means for something to be a trivially copyable type.

Cheers,

Anthony