On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits < llvm-comm...@lists.llvm.org> wrote:
> 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. > The source workaround solution *does not* scale. Most importantly, user may not even be aware of the problem (and performance loss) unless compiling the code with another compiler and notice the performance difference. David > > >> >> 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 >> > > _______________________________________________ > llvm-commits mailing list > llvm-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
