←back to thread

The provenance memory model for C

(gustedt.wordpress.com)
224 points HexDecOctBin | 2 comments | 30 Jun 25 09:25 UTC | HN request time: 0s | source
Show context
nikic ◴[30 Jun 25 20:45 UTC] No.44427669[source]▶
At least at a skim, what this specifies for exposure/synthesis for reads/writes of the object representation is concerning. One of the consequences is that dead integer loads cannot be eliminated, as they may have an exposure side effect. I guess C might be able to get away with it due to the interaction with strict aliasing rules. Still quite surprised that they are going against consensus here (and reduces the likelihood that these semantics will get adopted by implementers).
replies(4): >>44427836 #>>44428359 #>>44428989 #>>44432092 #
comex ◴[30 Jun 25 21:59 UTC] No.44428359[source]▶
> I guess C might be able to get away with it due to the interaction with strict aliasing rules.

But not for char-typed accesses. And even for larger types, I think you would have to worry about the combo of first memcpying from pointer-typed memory to integer-typed memory, then loading the integer. If you eliminate dead integer loads, then you would have to not eliminate the memcpy.

replies(1): >>44437436 #
1. nikic ◴[01 Jul 25 19:52 UTC] No.44437436[source]▶
That's a great point. I initially thought we could assume no exposure for loads with non-pointer-compatible TBAA, but you are right that this is not correct if the memory has been laundered through memcpy.
replies(1): >>44440646 #
2. uecker ◴[02 Jul 25 06:02 UTC] No.44440646[source]▶
You can still eliminate the memcpy of if you mark the pointer exposed at this point.