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

[Nuno Lopes via Phabricator via cfe-commits]

nlopes added a comment.

In D128501#3613420 <https://reviews.llvm.org/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 following:
>
> File A:
>
>   struct X { int a : 8; int b : 24; };
>   void f(struct X*);
>   int g() {
>       struct X x;
>       x.a = 10;
>       f(&x);
>       return x.a;
>   }
>
> File B:
>
>   struct X { int a : 8; int b : 24; };
>   void f(struct X* x) {
>       x->b = 10;
>   }
>
> If both files are compiled -ffine-grained-bitfield-accesses, the fields don't overlap.  If both files are compiled with -fno-fine-grained-bitfield-accesses, the assignment in file A freezes both fields of "x".  If file A is compiled with -ffine-grained-bitfield-accesses, but file B is not, f() corrupts the field "a", so g() returns poison (if I'm not missing anything?).

You are right, thanks! f() corrupts `a` because f assumes the fields were both initialized or neither of them was initialized.
The fix is not trivial though, because -ffine-grained-bitfield-accesses would have to freeze the adjacent fields.
This only matters if the IRs are linked together with IPO. Otherwise, at object level it doesn't really matter.

Do you think we can get away by just documenting the incompatibility of doing IPO with files compiled with different -ffine-grained-bitfield-accesses flags?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128501