Hi,

Thanks for forwarding the email to me Arthur.

On 22/02/2023 12:57, Arthur O'Dwyer wrote:
> On Tue, Feb 21, 2023 at 9:53 PM connor horman via Std-Proposals
> <std-proposals_at_[hidden]> 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