jdoerfert added a comment. > I'm still not seeing the issue fully. My understanding of the situation > (which may be wrong) is that Clang lowers to LLVM IR and adds noundef > markings at call sites that this patch attempts to let the user then undo. > However, why can Clang's CodeGen not notice the special builtin and walk up > the call chain to mark all the wrapper functions to ensure everything is > marked appropriately? There might be a small perf loss (if there are wrappers > around wrappers around wrappers kind of situation), but this means we don't > have to expose this problem to users.
I think you are right, we could identify shuffles and go up the call chain in clang (codegen) if we wanted. > I still think that a solution which doesn't require the user to make such > dangerous decisions on their own is a better design if we can accomplish it. This is a valid opinion but I don't see how this matches what we do (or has been done) in the past. I mean, there are plenty of command line options and attributes that do exactly this, let the user "define", or better "refine", semantics. The entire "initialize with 0" stuff comes to mind, making new things UB with -ffast-math and friends, overloadable, etc. --- All that said, I'm generally more in favor of explicit annotations in the source than implicit compiler magic to implement a special case. Others should chime in. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D130224/new/ https://reviews.llvm.org/D130224 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
