[PATCH] Add support for optimization reports.

Diego Novillo dnovillo at google.com
Thu Apr 3 11:14:58 PDT 2014


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?

> ================
> 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?


Diego.




More information about the cfe-commits mailing list