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

jmciver closed this revision. jmciver added a comment. I am closing this ticket as we are working on alternative solutions to poison based load semantics . Thanks to everyone for taking the time to discuss t

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

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.

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

rjmccall added a comment. In D128501#3613890 , @efriedma wrote: >> Is there no way in LLVM to load partially-initialized memory and then freeze >> it that will preserve the parts of the value that are initialized? Because >> that seems like something th

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

efriedma added a comment. > Is there no way in LLVM to load partially-initialized memory and then freeze > it that will preserve the parts of the value that are initialized? Because > that seems like something that LLVM needs to be providing. It's currently possible to `load <32 x i1>`, freeze

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

rjmccall added a comment. Is there no way in LLVM to load partially-initialized memory and then freeze it that will preserve the parts of the value that are initialized? Because that seems like something that LLVM needs to be providing. Repository: rG LLVM Github Monorepo CHANGES SINCE LAS

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

efriedma added a comment. > This only matters if the IRs are linked together with IPO. Otherwise, at > object level it doesn't really matter. Right. > Do you think we can get away by just documenting the incompatibility of doing > IPO with files compiled with different -ffine-grained-bitfield-

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

nlopes added a comment. In D128501#3613420 , @efriedma wrote: >> No, you can still link those. There's no ABI change nor any interference at >> IR level. > > The scenario I was thinking of with -ffine-grained-bitfield-accesses is > something like the fo

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

efriedma added a comment. > No, you can still link those. There's no ABI change nor any interference at > IR level. The scenario I was thinking of with -ffine-grained-bitfield-accesses is something like the following: File A: struct X { int a : 8; int b : 24; }; void f(struct X*); int g

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

nlopes added a comment. In D128501#3608846 , @efriedma wrote: > Under this scheme, is it illegal to link together object files built with > -ffine-grained-bitfield-accesses and object files built with > -fno-fine-grained-bitfield-accesses? No, you can

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

efriedma added a comment. Under this scheme, is it illegal to link together object files built with -ffine-grained-bitfield-accesses and object files built with -fno-fine-grained-bitfield-accesses? Do we want to add a temporary option to control this, to make it easier for people to benchmark

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

rjmccall accepted this revision. rjmccall added a comment. This revision is now accepted and ready to land. Seems right to me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128501/new/ https://reviews.llvm.org/D128501 _