Some Clang command-line handling code could benefit from the option's prefixed name being a StringLiteral. This patch changes the llvm::opt TableGen backend to generate and emit that into the .inc file.
Depends on D157028.
Paths
| Differential D157029
[llvm] Construct option's prefixed name at compile-time ClosedPublic Authored by jansvoboda11 on Aug 3 2023, 1:24 PM.
Details Summary Some Clang command-line handling code could benefit from the option's prefixed name being a StringLiteral. This patch changes the llvm::opt TableGen backend to generate and emit that into the .inc file. Depends on D157028.
Diff Detail
Event TimelineHerald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptAug 3 2023, 1:24 PM benlangmuir added inline comments.
jansvoboda11 retitled this revision from [llvm] Construct option spelling at compile-time to [llvm] Construct option's prefixed name at compile-time.Aug 4 2023, 11:57 AM jansvoboda11 added inline comments.
Comment Actions This increases the size of Info (static data size and static relocations). In return, some dynamic relocations are saved. Is this a net win? Comment Actions
If that's a concern, I can remove Info::Name and replace its usages with a function call that drops the prefix from prefixed name. Comment Actions
Done. Comment Actions LG! LLVMOption has users in llvm/ clang/ lldb/ lld/ clang-tools-extra/ flang/. You'll need to check that all the affected users are migrated... This revision is now accepted and ready to land.Aug 9 2023, 9:21 AM Closed by commit rG501f92d34382: [llvm] Construct option's prefixed name at compile-time (authored by jansvoboda11). · Explain WhyAug 9 2023, 9:52 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 547298 clang-tools-extra/clangd/CompileCommands.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Tooling/Tooling.cpp
llvm/include/llvm/Option/OptTable.h
llvm/include/llvm/Option/Option.h
llvm/lib/Option/OptTable.cpp
llvm/utils/TableGen/OptParserEmitter.cpp
|
This could use a doc comment to differentiate it from other string representations.
How does this compare with Arg::getSpelling? With Arg, IIUC the "spelling" is how it was actually written rather than a canonical form. That might be confusing if this one is canonical; so we should at least clearly document it or maybe put "canonical" in the API name?