[PATCH] Implement -Wframe-larger-than backend diagnostic

[Richard Smith]

+        if (isa<BlockDecl>(DC)) {
+          OS << "block function";
+          break;
+        }
+        if (isLambdaCallOperator(DC)) {
+          OS << "lambda function";
+          break;
+        }

Neither of these terms are used in any existing diagnostics, nor in the
relevant specifications. Maybe "block literal" and "lambda expression"
would be more appropriate? Also, have you considered using "lambda
expression within <name of surrounding entity>" or similar?

On Mon, Jun 2, 2014 at 5:51 AM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> Just some quick notes:
>
> const Decl *Demangle
>
> should probably be demangle, or maybe a getDeclForMangledName, since
> it does more than demangle a string.
>
> +  bool LookupRepresentativeDecl(
>
> should start with a lowercase.
>
> And a big thanks. This should let us produce far better diagnostics
> for things that involve mangled names, like aliases!
>
> btw, this also improves things a bit for pr18188, right?
>
>
> On 30 May 2014 12:23, Alp Toker <alp at nuanti.com> wrote:
> > The attached patch adds driver and frontend support for the GCC
> > -Wframe-larger-than=bytes warning.
> >
> > As the first GCC-compatible backend diagnostic built around LLVM's
> reporting
> > feature the patch adds infrastructure to perform reverse lookup from
> mangled
> > names emitted after LLVM code generation. Using that we resolve precise
> > locations and originating AST functions, lambdas or block declarations to
> > provide rich codegen-guided diagnostics.
> >
> > Supporting changes:
> >   * Get rid of the old MangleBuffer class that was only used for blocks
>

Can you split out / commit this separately?


> >   * Let StringMap maintain unique mangled name strings instead of
> allocating
> > copies
>

Do you have an feel for / have you measured the memory usage before and
after this patch? I'm not expecting any big surprises here, since we were
retaining storage for the mangled names anyway, but it'd be nice to have
the extra confidence.

> The test intentionally conflates driver, frontend and backend facilities
> for
> > now, and I expect parts of the approach to evolve as we get a feel for
> how
> > it'll play ball with LTO etc.
>

We need to have a fallback codepath for the case where the lookup fails; am
I right to assume that LTO (and IR from imported modules, and so on) would
take that path and gracefully degrade?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140602/ef020504/attachment.html>