On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits < cfe-commits@lists.llvm.org> wrote:
> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator < > revi...@reviews.llvm.org> wrote: > >> chandlerc added a comment. >> >> I'm really not a fan of the degree of complexity and subtlety that this >> introduces into the frontend, all to allow particular backend optimizations. >> >> I feel like this is Clang working around a fundamental deficiency in LLVM >> and we should instead find a way to fix this in LLVM itself. >> >> As has been pointed out before, user code can synthesize large integers >> that small bit sequences are extracted from, and Clang and LLVM should >> handle those just as well as actual bitfields. >> >> Can we see how far we can push the LLVM side before we add complexity to >> Clang here? I understand that there remain challenges to LLVM's stuff, but >> I don't think those challenges make *all* of the LLVM improvements off the >> table, I don't think we've exhausted all ways of improving the LLVM changes >> being proposed, and I think we should still land all of those and >> re-evaluate how important these issues are when all of that is in place. >> > > The main challenge of doing this in LLVM is that inter-procedural > analysis (and possibly cross module) is needed (for store forwarding > issues). > > Wei, perhaps you can provide concrete test case to illustrate the issue so > that reviewers have a good understanding. > It doesn't seem like all options for addressing that have been exhausted. And even then, I feel like trying to fix this with non-obvious (to the programmer) frontend heuristics isn't a good solution. I actually *prefer* the source work around of "don't use a bitfield if you *must* have narrow width access across modules where the optimizer cannot see enough to narrow them and you happen to know that there is a legal narrow access that works". Because that way the programmer has *control* over this rather than being at the whim of whichever side of the heuristic they end up on. > > David > >> >> >> Repository: >> rL LLVM >> >> https://reviews.llvm.org/D36562 >> >> >> >> _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits