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