llvm dev - Nov 2018 - New llvm.commandline named metadata

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

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. 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/8b8d9b3d/attachment.html>

> 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