[PATCH] D128501: [CodeGen] Make uninitialized Lvalue bit-field stores poison compatible

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> Is that seen as a defect or as for some reason desirable? Because I worry that optimizer people are talking themselves into something that would be a truly beautiful model if only there were a frontend that could emit code for it.
>
> Doesn't this make it e.g. illegal to use large integer types to do a memcpy of anything that might contain uninitialized padding?

Yes, it does make that illegal.  I think there's still significant gap here.

To allow implementing memcpy using large integers, given we have poison, basically, the possible solutions I know of are:

- Adopt byte types (https://lists.llvm.org/pipermail/llvm-dev/2021-June/150883.html).
- Adopt some rule that allows partially-poisoned integers, which are treated as poison except for a restricted set of operations, like freeze/store/bitcast.  (https://discourse.llvm.org/t/a-memory-model-for-llvm-ir-supporting-limited-type-punning/61948).
- Add some mechanism to perform a frozen load, that doesn't propagate poison across bit positions.
- Get rid of poison, and depend purely on undef.  (undef can be made self-consistent... but it's very hard to understand and doesn't allow optimizations we want.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128501/new/

https://reviews.llvm.org/D128501