[PATCH] Add new debug kind LocTrackingOnly.

Diego Novillo dnovillo at google.com
Mon Jun 23 14:34:37 PDT 2014


On Mon, Jun 23, 2014 at 5:33 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Mon, Jun 23, 2014 at 2:29 PM, Diego Novillo <dnovillo at google.com>
> wrote:
> >
> >
> >
> > On Mon, Jun 23, 2014 at 4:31 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >> ================
> >> Comment at: include/llvm/IR/DIBuilder.h:112
> >> @@ +111,3 @@
> >> +    /// @param Kind     The kind of debug information to generate.
> >> +    /// @param EmitDebugInfo   A boolean flag which indicates whether
> >> debug
> >> +    ///                        information should be written to the
> final
> >> ----------------
> >> I wonder if there's a less vague name we could use for this parameter,
> but
> >> I haven't thought of a better one yet. (I imagine inverted would make
> more
> >> sense - true for "use this weird thing where we make metadata nodes but
> >> don't add the CUs to the list" - but still don't know what we'd name it)
> >
> > Not sure what you consider vague about it. In my mind, this distinguishes
> > the generation of the debug info from its emission.  I'll gladly rename
> it
> > to something else if you can think of another way of naming this flow.
>
> Sorry, to clarify - what I consider vague about it, or what goes
> through my head when I see it is "all this code is about generating
> debug info (or, alternatively: this metadata /is/ the debug info),
> what does it mean to not generate debug info when we're clearly in
> code generating debug info".
>

Right. That's why it's named 'Emit'. To distinguish it from 'Generate'. We
still generate it, we just throw it into the bit bucket at the end.


>
> It'll probably be more obvious if/when we make the changes that are a
> bit more explicit about this - just producing scopes/file names, then
> we won't be building unused compile_units and other such things


Yeah. Could be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140623/7e8fff95/attachment.html>


More information about the llvm-commits mailing list