[PATCH] Add support for optimization reports.

[Richard Smith]

On Thu, Apr 3, 2014 at 11:14 AM, Diego Novillo <dnovillo at google.com> wrote:

> On Thu, Apr 3, 2014 at 2:04 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >
> >   Looks mostly fine. I'm concerned about a -R option affecting the debug
> info that ends up in the object file. I'm also concerned that the
> diagnostic quality will degrade if you build with no debug info enabled at
> all.
> >   It seems to me that if we can afford the IR size increase from
> `-dwarf-column-info`, we can afford the IR size increase from storing the
> frontend's notion of 'source location' into the IR, and that would allow us
> to do the right thing without `-g` and to deal properly with macro
> expansions etc. (It's only 32 bits per location...)
>
> But we *do* enable line table information when -Rpass= is given. We
> also enable column information, so all we alter is that we'll be
> emitting dwarf LOCs in final codegen.
>
> If you don't think dwarf LOC generation is fine, we could do one of two
> things:
>
> 1- We already have srcloc metadata. It would be a matter of generating
> them on every IR node when -Rpass= is used.
> 2- If -Rpass= is used but we found it necessary to force line and
> column table generation, we could note that so that the code generator
> out of the back end does not emit DWARF LOCs. Eric, if this doesn't
> sound silly to you, how hard would it be?


I think either of these could work. Option 1 seems cleaner to me, and has
the advantage of preserving macro and inclusion information. We could
probably piggyback on the debug location emission code to emit the !srcloc
in the right places.

> ================
> > Comment at: lib/Frontend/CompilerInvocation.cpp:523
> > @@ -522,1 +522,3 @@
> >
> > +  if (Arg *A = Args.getLastArg(OPT_Rpass_EQ)) {
> > +    StringRef Val = A->getValue();
> > ----------------
> > ... so we take the last -Rpass= option, rather than combining them? I
> find that unintuitive, FWIW, but maybe this is the right model.
>
> I could combine them with '|'. Perhaps, that's a more intuitive model
> for the command line. How's that sound?


Sounds good to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140403/309cf1b9/attachment.html>