Patch D96280 moved command line round-tripping from each parsing functions into single `CreateFromArgs` function.
This patch cleans up the individual parsing functions, essentially merging `ParseXxxImpl` with `ParseXxx`, as the distinction is not necessary anymore.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96323
Finally, this patch moves from round-tripping one `CompilerInvocation` at a time to round-tripping the invocation as a whole.
This patch includes only the code required to make round-tripping the whole invocation work. More cleanups will be done in a follow-up patch.
Depends on D96847, D97041 & D97042.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96280
After a revision of D96274 changed `DiagnosticOptions` to not store all remark arguments **as-written**, it is no longer possible to reconstruct the arguments accurately from the class.
This is caused by the fact that for `-Rpass=regexp` and friends, `DiagnosticOptions` store only the group name `pass` and not `regexp`. This is the same representation used for the plain `-Rpass` argument.
Note that each argument must be generated exactly once in `CompilerInvocation::generateCC1CommandLine`, otherwise each subsequent call would produce more arguments than the previous one. Currently this works out because of the way `RoundTrip` splits the responsibilities for certain arguments based on what arguments were queried during parsing. However, this invariant breaks when we move to single round-trip for the whole `CompilerInvocation`.
This patch ensures that for one `-Rpass=regexp` argument, we don't generate two arguments (`-Rpass` from `DiagnosticOptions` and `-Rpass=regexp` from `CodeGenOptions`) by shifting the responsibility for handling both cases to `CodeGenOptions`. To distinguish between the cases correctly, additional information is stored in `CodeGenOptions`.
The `CodeGenOptions` parser of `-Rpass[=regexp]` arguments also looks at `-Rno-pass` and `-R[no-]everything`, which is necessary for generating the correct argument regardless of the ordering of `CodeGenOptions`/`DiagnosticOptions` parsing/generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96847
We can now express all marshalling semantics in `Opt{In,Out}FFlag` via `BoolFOption`.
This patch moves remaining `Opt{In,Out}FFlag` instances using marshalling to `BoolFOption` and removes marshalling capabilities from `Opt{In,Out}FFlag` entirely.
This simplifies the decisions developers have to make when creating new boolean options:
* For simple cc1 flag pairs, use `Bool{,F,G}Option`.
* For cc1 flag pairs that require complex marshalling logic, use `Opt{In,Out}FFlag` and implement marshalling manually.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D97370
This patch responds to a comment from @vitalybuka in D96203: suggestion to
do the change incrementally, and start by modifying this file name. I modified
the file name and made the other changes that follow from that rename.
Reviewers: vitalybuka, echristo, MaskRay, jansvoboda11, aaron.ballman
Differential Revision: https://reviews.llvm.org/D96974
This patch moves the creation of the '-Wspir-compat' argument from cc1 to the driver.
Without this change, generating command line arguments from `CompilerInvocation` cannot be done reliably: there's no way to distinguish whether '-Wspir-compat' was passed to cc1 on the command line (should be generated), or if it was created within `CompilerInvocation::CreateFromArgs` (should not be generated).
This is also in line with how other '-W' flags are handled.
(This was introduced in D21567.)
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D97041
This patch stops creating the '-Wno-stdlibcxx-not-found' argument in `CompilerInvocation::CreateFromArgs`.
The code was added in 2e7ab55e657f (a follow-up to D48297). However, D61963 removes relevant tests and starts explicitly passing '-Wno-stdlibcxx-not-found' to the driver. I think it's fair to assume this is a dead code.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D97042
Basic block sections enables function sections implicitly, this is not needed
and is inefficient with "=list" option.
We had basic block sections enable function sections implicitly in clang. This
is particularly inefficient with "=list" option as it places functions that do
not have any basic block sections in separate sections. This causes unnecessary
object file overhead for large applications.
This patch disables this implicit behavior. It only creates function sections
for those functions that require basic block sections.
This patch is the second of two patches and this patch removes the implicit
enabling of function sections with basic block sections in clang.
Differential Revision: https://reviews.llvm.org/D93876
This patch generates the `-f[no-]finite-loops` arguments from `CompilerInvocation` (added in D96419), fixing test failures of Clang built with `-DCLANG_ROUND_TRIP_CC1_ARGS=ON`.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D96761
This patch adds 2 new options to control when Clang adds `mustprogress`:
1. -ffinite-loops: assume all loops are finite; mustprogress is added
to all loops, regardless of the selected language standard.
2. -fno-finite-loops: assume no loop is finite; mustprogress is not
added to any loop or function. We could add mustprogress to
functions without loops, but we would have to detect that in Clang,
which is probably not worth it.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D96419
Some Windows build bots report `FileSystemOpts` and `MigratorOpts` as undeclared. This fix renames the parameter and declares a local variable with the original name.
This patch splits out the last two option groups (`Filesystem` and `Migrator`) into their own `Parse`/`Generate` functions.
This effectively removes the need for `parseSimpleArgs` and marshalling block in `CompilerInvocation::generateCC1CommandLine`.
The two new `Parse`/`Generate` functions are not part of the round-trip, because they contain no custom code and the very next patch starts round-tripping the whole `CompilerInvocation`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96278
This patch implements generation of remaining diagnostic options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96274
This patch implements generation of remaining dependency output options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96273
This patch implements generation of remaining target options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96158
This patch implements generation of remaining preprocessor output options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96156
This patch implements generation of remaining frontend options and tests it by performing parse-generate-parse round trip.
Depends on D96269.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96155
This patch extracts the mapping between command line option and frontend::ActionKind into a table. The table can be reused when parsing and also generating command line options.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96269
This patch stores the `InputKind` (parsed mainly from `-x`) to `FrontendOptions`. This is necessary for command line generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96149
This patch implements generation of remaining codegen options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D96056
Regular expression patterns passed through the command line are being used to create an instances of `llvm::Regex` and thrown away.
There is no API to serialize `Regex` back to the original pattern. This means we have no way to reconstruct the original pattern from command line. This is necessary for serializing `CompilerInvocation`.
This patch stores the original pattern string in `CodeGenOptions` alongside the `llvm::Regex` instance.
Reviewed By: dexonsmith, thegameg
Differential Revision: https://reviews.llvm.org/D96036
This patch implements generation of remaining language options and tests it by performing parse-generate-parse round trip (on by default for assert builds, off otherwise).
This patch also correctly reports failures in `parseSanitizerKinds`, which is necessary for emitting diagnostics when an invalid sanitizer is passed to `-fsanitize=` during round-trip.
This patch also removes TableGen marshalling classes from two options:
* `fsanitize_blacklist` When parsing: it's first initialized via the generated code, but then also changed by manually written code, which is confusing.
* `fopenmp` When parsing: it's first initialized via generated code, but then conditionally changed by manually written code. This is also confusing. Moreover, we need to do some extra checks when generating it, which would be really cumbersome in TableGen. (Specifically, not emitting it when `-fopenmp-simd` was present.)
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95793
This patch added a distinct CUID for each input file, which is represented by InputAction.
clang initially creates an InputAction for each input file for the host compilation. In CUDA/HIP action
builder, each InputAction is given a CUID and cloned for each GPU arch, and the CUID is also cloned. In this way,
we guarantee the corresponding device and host compilation for the same file shared the
same CUID. On the other hand, different compilation units have different CUID.
-fuse-cuid=random|hash|none is added to control the method to generate CUID. The default
is hash. -cuid=X is also added to specify CUID explicitly, which overrides -fuse-cuid.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D95007
This reverts commit 6039f821 and reapplies bff6d9bb.
Clang's Index/implicit-attrs.m test invokes c-index-test with -fobjc-arc. This flag is not compatible with -fobjc-runtime=gcc, which gets implied on Linux.
The original commit uncovered this by correctly reporting issues when parsing -cc1 command line.
This commit fixes the test to explicitly provide ObjectiveC runtime compatible with ARC.
This patch correctly reports success/failure of `ParseLangArgs`. Besides being consistent with other `Parse` functions, this is required to make round-tripping of `LangOptions` work.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95792
This patch implements generation of remaining preprocessor options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95366
This patch implements generation of remaining analyzer options and tests it by performing parse-generate-parse round trip.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95369
OpenCL keywords 'pipe' and 'generic' are unconditionally
supported for OpenCL C 2.0 or in OpenCL C++ mode. In OpenCL C 3.0
these keywords are available if corresponding optional core
feature is supported.
Reviewed By: Anastasia, svenvh
Differential Revision: https://reviews.llvm.org/D95778
This patch implements generation of remaining header search arguments.
It's done manually in C++ as opposed to TableGen, because we need the flexibility and don't anticipate reuse.
This patch also tests the generation of header search options via a round-trip. This way, the code gets exercised whenever Clang is built and tested in asserts mode. All `check-clang` tests pass.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D94472
This reverts commit 9ad94c12
It turns out that to correctly generate command line flags for LangOptions::OpenMP and LangOptions::OpenMPSimd, we need the flexibility of C++.
This patch makes all macros forwarding to `PARSE_OPTION_WITH_MARSHALLING` and `GENERATE_OPTION_WITH_MARSHALLING` variadic.
Sice we will be splitting up all CompilerInvocation parts, this will allow us to avoid a lot of boilerplate code.
The local macros prefix forwarded arguments with local variables required by the main macros. The `{THIS,NO}_PREFIX` macros make it possible for forwarding macros in member functions (`parseSimpleArgs`, `generateCC1CommandLine`) to prefix keypaths with `this->`. (Some build bots seem to require that.)
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95532
This patch moves parsing of header search options from `generateCC1Options` to separate `GenerateHeaderSearchArgs`.
The round-trip algorithm in D94472 requires this separation to be able to run parsing and generating **only** for the options that need to be tested via round-tripping.
This also moves the `GENERATE_OPTION_WITH_MARSHALLING` to the top of the file, because other kinds of options will be generated in separate functions that will be spread throughout `CompilerInvocation.cpp` to be close to their parsing counterparts.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D94803
This patch moves parsing of header search options from `parseSimpleArgs` back to `ParseHeaderSearchArgs` where they originally were.
The round-trip algorithm in D94472 requires this separation to be able to run parsing and generating **only** for the options that need to be tested via round-tripping.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D94802
Port some OpenMP-related language options to the marshalling system for automatic command line parsing and generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95348
Port some miscellaneous language options to the marshalling system for oautomatic command line parsing and generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95347
Port some miscellaneous language options to the marshalling system for oautomatic command line parsing and generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95346
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
Port some GPU-related language options to the marshalling system for automatic command line parsing and generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95345
Port some GNU-related language options to the marshalling system for automatic command line parsing and generation.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95343
