[llvm-dev] New llvm.commandline named metadata

[Reid Kleckner via llvm-dev]

Wow, I don't know how I missed that. I touched the codeview parts of this a
few weeks ago in r344393, and I looked at DICompileUnit, but the field is
called "Flags" and it didn't occur to me that those would be *compiler*
flags. Today I learned. I knew we wanted this, I just didn't know it was
implemented.

With that in mind, if you want to embed the command line into the object
file separately from the debug info, I guess it's reasonable to put it in
the metadata in two places: once in the DICompileUnit and again in the
named metadata. It helps keep separate concerns separate.

On Tue, Nov 13, 2018 at 1:14 PM Adrian Prantl <aprantl at apple.com> wrote:

>
> > On Nov 13, 2018, at 1:07 PM, Reid Kleckner <rnk at google.com> wrote:
> >
> > Overall, I think we should do this. It's one of the most popular out of
> tree extensions that people make to LLVM and clang, and we want it for
> codeview anyway.
>
> Why isn't OPT_dwarf_debug_flags good enough for codeview?
>
> -- adrian
>
> > We currently don't emit a command line there. Other than that, I have
> some questions about how to do it.
> >
> > How will you associate the command line with the compilation unit to
> deal with regular (fat, not thin) LTO? It looks like you don't:
> >       assert(N->getNumOperands() == 1 &&
> >              "llvm.commandline metadata entry can have only one
> operand");
> >
> > IR linking will concatenate the named metadata nodes into a list of all
> the command lines. What should the semantics be? During regular object
> linking, I assume the command lines are discarded. Maybe just code that up?
> >
> > On Tue, Nov 13, 2018 at 12:27 PM via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
> > Hi llvm-dev,
> >
> > I have an implementation of -frecord-gcc-switches ready for Clang, and a
> > named metadata node seemed like the correct way to approach this on the
> > LLVM side. I have a review at https://reviews.llvm.org/D54487 which
> > discusses some of the differences in implementation vs. GCC. A change to
> > the set of "special" named metadata nodes seems like something that
> > warrants an llvm-dev post, and I was not sure who specifically would be
> > interested in reviewing the changes.
> >
> > Thanks,
> > Scott
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181113/49acad80/attachment.html>