Adrian Prantl via llvm-dev
2018-Nov-13 21:14 UTC
[llvm-dev] New llvm.commandline named metadata
> 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
Reid Kleckner via llvm-dev
2018-Nov-13 21:27 UTC
[llvm-dev] New llvm.commandline named metadata
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>
Hi Reid, I might be misunderstanding your original question, but in the IR llvm.commandline behaves the same as llvm.ident. The IR linker handles merging multiple named metadata (see test/Linker/commandline.ll), and in the code-object multiple command-lines are emitted separated by null bytes (see test/MC/ELF/commandline.s). The object linker can merge these sections and retain all of the individual command-lines just fine. The assert you mention just requires each individual command-line be comprised of exactly one element. Giving any meaning to the command-lines relative to other compilation units is up to whoever is interpreting them; they are just a set of strings. Regards, Scott On 2018-11-13 16:27, Reid Kleckner wrote:> 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 [1] >> 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 [2] > > > Links: > ------ > [1] https://reviews.llvm.org/D54487 > [2] http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev