[PATCH] D49771: CodeGen: use non-zero memset when possible for automatic variables

JF Bastien via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jul 31 16:07:58 PDT 2018


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





More information about the cfe-commits mailing list