On Thu, Apr 3, 2014 at 2:04 PM, Richard Smith <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
