| Issue |
180951
|
| Summary |
Clarify semantics for non-whole-byte loads and stores
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
RalfJung
|
This came up briefly in the last formal semantics WG call; it seems worth at least having an issue for it. Cc @nikic @nunoplopes
The LangRef currently states:
> When loading a value of a type like i20 with a size that is not an integral number of bytes, the result is undefined if the value was not originally written using a store of the same type.
This sentence is doing a lot of work -- it means that memory *remembers* the size of a store that was used to store any particular byte in memory. This is extra "hidden" state, but the LangRef does not clarify how that hidden state interacts with other operations such as `memcpy`. This sentence also implies that if I store an `i1`, then load a `b8` (from the byte type proposal), store that `b8` back unchanged, and load an `i1` again, the result is undefined since the value was written with a `b8` store, not a `i1` store. In other words, introducing simple load-store roundtrips can cause UB, counteracting a key part of the motivation of the byte type which is to be able to exactly represent and roundtrip arbitrary memory contents. Is that really the intended behavior?
It would save a lot of headache if the behavior of load was changed to not depend on the type that was used to store the value, but just on the value itself. The docs for `store` already say:
> When writing a value of a type like i20 with a size that is not an integral number of bytes, it is unspecified what happens to the extra bits that do not belong to the type, but they will typically be overwritten.
In the meeting, @nikic mentioned that this wording mostly exists to avoid nailing down whether such a store will do zero-extension or sign-extension. Wouldn't it suffice to say that such a store resets the remaining bits to poison (and say nothing special about loads, except maybe to clarify that an `i20` load is not affected by extra bits in the same bytes being poison)? Or is there some particular behavior this does not explain?
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
