seaneveson added a comment. In http://reviews.llvm.org/D12358#234949, @zaks.anna wrote:
> We try to avoid false positives as much as possible. They are very painful > for users to deal with. > You should develop this feature behind a flag. This would allow for > incremental development and simplify evaluation. I absolutely want to minimize false positives, but I also want to make a start on just doing something after the loop, where the solution could then be improved upon. Developing behind a flag seems to be an ideal solution to me. In http://reviews.llvm.org/D12358#234975, @krememek wrote: > I think the functionality started here by doing something clever with loops > is complex enough to warrant putting this into a separate .cpp file. Good idea. In http://reviews.llvm.org/D12358#234986, @krememek wrote: > I do wonder if nested loops will cause a problem here Yes the patch only works with the inner most loop. A fix to this should ideally prevent inner loops being analyzed again from an identical state. I haven’t looked into if this will ‘just happen’ as a result of the framework, or how to do it otherwise. In http://reviews.llvm.org/D12358#234977, @krememek wrote: > I think we’d all be quite amendable for this work to go in under a flag, with > further improvements going in on top of that. That way we can all > collectively start hashing this out in trunk instead of feature creeping a > patch. If I refactor this patch in its current state into a separate file and put it behind a flag, would it then be acceptable? I would then like to take some time to look at the invalidation improvements as discussed in this thread. http://reviews.llvm.org/D12358 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
