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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
