[PATCH] D79249: [NOT FOR REVIEW] Experimental support for zero-or-trap behavior foruninitialized variables.

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

Overall I like this approach.

I think it needs three more things to make it:

- Better size optimizations. I measured the code size impact on a codebase which deploys variable auto-init already, and it's a 0.5% code size hit. Considering that auto-init itself was 1%, it means the mitigation now costs 50% more. I haven't dug into why the increase is such, and I assume that there's low-lying fruits.
- I haven't measure performance impact. It might be zero.
- I think we'd need opt remarks support, because we'd want to audit all the places where a trap is left behind.



================
Comment at: clang/lib/CodeGen/CGDecl.cpp:1166
+          &CGM.getModule(), llvm::Intrinsic::trapping, {V->getType()});
+      V = Builder.CreateCall(TrapFn, {V});
+    }
----------------
Here you need something like:
```
      auto *PointerTy = Ty->getPointerTo(Loc.getAddressSpace());
      if (V->getType() != PointerTy)
        Loc = Builder.CreateBitCast(Loc, PointerTy);
```
Because you can be storing a constant which is layout-compatible with the location, but which doesn't have the same type (say, when we have an explicit padding array of bytes). Line 1184 does that already for other code paths.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79249