jfb added a comment. In https://reviews.llvm.org/D49771#1183562, @mehdi_amini wrote:
> In https://reviews.llvm.org/D49771#1183380, @jfb wrote: > > > In https://reviews.llvm.org/D49771#1181008, @mehdi_amini wrote: > > > > > I'm curious: isn't the kind of optimization we should expect LLVM to > > > provide? > > > > > > Maybe? It seems obvious to do here since we know we'll probably want to be > > doing it, and I have another patch I'm working on which will make it that > > much more obviously useful to have here. The middle-end can definitely > > figure it out but it just seems like more work, later, so in the meantime > > we'd be looking at more stuff. > > > I'm not asking where is it easier to do, but where does it make the most > sense :) What I mean by "easy" is: we know we're likely to want this type of code, there's not much pattern recognition needed on our part here. Were we to wait we'd need to do more work. I believe this statement will become truer over time. > Doing such in LLVM in general means catching more patterns (i.e. after > inlining, etc.), and also catching it from multiple frontend. So in general > I'm worried when I see optimizations implemented in the frontend instead of > the middle end. Agreed, LLVM could also do it, and it would likely be useful to do so. I'm worried, however, about generating a bunch more code than needed from clang in the hopes that the compiler will clean it up later. Repository: rL LLVM https://reviews.llvm.org/D49771 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
