4 ms·
The linked thread doesn't say exactly how, but I can construct some way in my head: Final 32-bit store effectively stores two 16-bit values or'ed together as h
by compiler-guy 3y ago
The linked thread doesn't say exactly how, but I can construct some way in my head:
Final 32-bit store effectively stores two 16-bit values or'ed together as high-16 and low-16. You can get this without any shifting and simple addition and the proper values. If these two sixteen bit values are calculated along two very different paths which have different lengths, the compiler might opt to spill one of them early, only to reload the spilled value just before the final addition.
From there it isn't too hard to see some liveness analysis determine that the reload, addition, and immediate store affect onlye bits of the final store, and you can remove parts of it.
Pure speculation on my part that this is what happened, but all of these intermediate steps are performed all the time by modern optimizing compilers.
- _nalply 3y agoOr if I understood it correctly, there are platforms like CHERI which have metadata about memory, for example to detect invalid access. This metadata might race with the data itself.
- jrtc27 3y agoThe hardware must, and does, ensure that the metadata (both addressable - bounds, permissions, etc - and non-addressable - the tag) is kept atomic with the address portion of the capability, as otherwise you would be able to forge capabilities via such races. That is, you will never see a torn capability write, and the tag is updated atomically with every write, capability or not. This is easy to do since capabilities are always within a single cache line.