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

2020-06-18 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment. FWIW, I tried to solve something similar the other day. My solution sketch looked like this: https://godbolt.org/z/bRQPjd The idea would be that we teach DSE (and others) to remove the `llvm.undef.init` intrinsic if the location is overwritten. In the example above

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

2020-06-17 Thread 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

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

2020-05-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith updated this revision to Diff 261511. rsmith added a comment. - The second operand of 'store' is the pointer, not the first. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79249/new/ https://reviews.llvm.org/D79249 Files:

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

2020-05-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith created this revision. Herald added subscribers: llvm-commits, cfe-commits, jdoerfert, hiraditya. Herald added projects: clang, LLVM. rsmith updated this revision to Diff 261511. rsmith added a comment. - The second operand of 'store' is the pointer, not the first. Add @llvm.trapping.()