llozano added a comment. In D77168#1988138 <https://reviews.llvm.org/D77168#1988138>, @srhines wrote:
> In D77168#1988122 <https://reviews.llvm.org/D77168#1988122>, @jfb wrote: > > > In D77168#1988049 <https://reviews.llvm.org/D77168#1988049>, @srhines wrote: > > > > > `pragma clang attribute` is interesting, but how do you apply that in a > > > selective fashion to local variables (especially in a way that can be > > > automated)? At first, I didn't think the goal for this should be to > > > create a frequently used option for **most** end users, but I do think > > > that it could be quite useful for more folks when debugging, especially > > > if it is easy to automate (which optimization-fuel approaches are, while > > > pragmas are not). > > > > > > `__attribute__((uninitialized))` for more selectiveness :) > > > > Of course, not automated. In general we don't really automate compiler > > things of this sort, say UBSan. OptRemarks is the best we really have to > > dig into these things. One other option would be to truly randomize the > > init pattern: emit a handful of different byte patterns, and then see the > > crash caused by a different pattern, and track it back to which local > > variable got that byte pattern. > > > That's just it though. This technique is tried and true in other > compilers/tools. Why should we let past history dictate whether to facilitate > automation in the present/future? Rather than having to "track it back", you > can let the tooling do it for you. It gets you at least a breakage related to > this transformation, and the best part is you can fix that one, and then run > it again to chase down further issues. All without modifying source code. I > feel like I can't be the only one who has used these kinds of tools for > debugging transformations before, hence why I feel so invested in making this > easy for everyone (compiler devs and regular users). UBSan isn't as relevant > as it can provide diagnostics for the particular instance in which it was > tripped. If we wanted to do something similar for initialization, we would > have to mark the uninitialized value and track down any potential use of it, > which seems like a lot more complexity and decreased performance too. I totally agree with the value of automatic triaging of compiler transformations. My team uses techniques like that quite often. It may be relatively easy to triage a failure caused/exposed by a compiler transformation when you are applying to a single package that you have some familiarity with. It is totally different when you are trying to apply a new compiler transformation to a platform made up of hundreds (or thousands) of packages you are not familiar with. If this feature becomes more popular, a lot of compiler users will benefit from having mechanisms to automatic triage initializations that change program behavior. This is useful not only for compiler developers but also for compiler users. The pragma attribute push functionality is useful but I see that as complimentary to what this change is proposing. It allows developers more flexibility on what gets the transformation applied and a larger granularity but it is not as convenient for bisection since it needs source code changes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77168/new/ https://reviews.llvm.org/D77168 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
