[clang][cli] Parse HeaderSearch options separately

This patch moves parsing of header search options from `parseSimpleArgs` back to `ParseHeaderSearchArgs` where they originally were.

The round-tri

[clang][cli] Parse HeaderSearch options separately

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

show more ...

[clang][cli] Port OpenMP-related LangOpts to marshalling system

Port some OpenMP-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By: d

[clang][cli] Port OpenMP-related LangOpts to marshalling system

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

show more ...

[clang][cli] Port LangOpts to marshalling system, pt.2

Port some miscellaneous language options to the marshalling system for oautomatic command line parsing and generation.

Reviewed By: dexonsmith

[clang][cli] Port LangOpts to marshalling system, pt.2

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

show more ...

[clang][cli] Port LangOpts to marshalling system, pt.1

Port some miscellaneous language options to the marshalling system for oautomatic command line parsing and generation.

Reviewed By: dexonsmith

[clang][cli] Port LangOpts to marshalling system, pt.1

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

show more ...

Support for instrumenting only selected files or functions

This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
saniti

Support for instrumenting only selected files or functions

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

show more ...

Add -fbinutils-version= to gate ELF features on the specified binutils version

There are two use cases.

Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
featu

Add -fbinutils-version= to gate ELF features on the specified binutils version

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=36727 https://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

show more ...

Revert "Support for instrumenting only selected files or functions"

This reverts commit 4edf35f11a9e20bd5df3cb47283715f0ff38b751 because
the test fails on Windows bots.

Support for instrumenting only selected files or functions

This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
saniti

Support for instrumenting only selected files or functions

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

show more ...

[clang][cli] Port GPU-related language options to marshalling system

Port some GPU-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By:

[clang][cli] Port GPU-related language options to marshalling system

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

show more ...

[clang][cli] Port GNU language options to marshalling system

Port some GNU-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By: dexonsm

[clang][cli] Port GNU language options to marshalling system

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

show more ...

[clang][cli] Store LangStandard::Kind in LangOptions

The `LangStandard::Kind` parsed from command line arguments is used to set up some `LangOption` defaults, but isn't stored anywhere.

To be able

[clang][cli] Store LangStandard::Kind in LangOptions

The `LangStandard::Kind` parsed from command line arguments is used to set up some `LangOption` defaults, but isn't stored anywhere.

To be able to generate `-std=` (in future patch), we need `CompilerInvocation` to not forget it.

This patch demonstrates another use-case: using `LangStd` to set up defaults of marshalled options.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D95342

show more ...

[clang] Add -fprofile-prefix-map

This flag allows you to re-write absolute paths in coverage data analogous to -fdebug-prefix-map. This flag is also implied by -ffile-prefix-map.

[clang][cli] Port visibility LangOptions to marshalling system

This patch introduces Clang-specific MarshallingInfoVisibility TableGen class.

Reviewed By: dexonsmith

Differential Revision: https:/

[clang][cli] Port visibility LangOptions to marshalling system

This patch introduces Clang-specific MarshallingInfoVisibility TableGen class.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D95147

show more ...

[clang][cli] Port more options to new parsing system

This patch adds marshalling information to more options.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D94957

[clang][cli] Parse Lang and CodeGen options separately

This patch moves the parsing of `{Lang,CodeGen}Options` from `parseSimpleArgs` to the original `Parse{Lang,CodeGen}Args` functions.

This ensur

[clang][cli] Parse Lang and CodeGen options separately

This patch moves the parsing of `{Lang,CodeGen}Options` from `parseSimpleArgs` to the original `Parse{Lang,CodeGen}Args` functions.

This ensures all marshalled `LangOptions` are being parsed **after** the call `setLangDefaults`, which in turn enables us to marshall `LangOptions` that somehow depend on the defaults. (In a future patch.)

Now, `CodeGenOptions` need to be parsed **after** `LangOptions`, because `-cl-mad-enable` (a `CodeGenOpt`) depends on the value of `-cl-fast-relaxed-math` and `-cl-unsafe-math-optimizations` (`LangOpts`).

Unfortunately, this removes the nice property that marshalled options get parsed in the exact order they appear in the `.td` file. Now we cannot be sure that a TableGen record referenced in `ImpliedByAnyOf` has already been parsed. This might cause an ordering issues (i.e. reading value of uninitialized variable). I plan to mitigate this by moving each `XxxOpt` group from `parseSimpleArgs` back to their original parsing function. With this setup, if an option from group `A` references option from group `B` in TableGen, the compiler will require us to make the `CompilerInvocation` member for `B` visible in the parsing function for `A`. That's where we notice that `B` didn't get parsed yet.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94682

show more ...

[clang][cli] NFC: Promote ParseLangArgs and ParseCodeGenArgs to members

This patch promotes `ParseLangArgs` and `ParseCodeGenArgs` to members of `CompilerInvocation`. That will be useful in the foll

[clang][cli] NFC: Promote ParseLangArgs and ParseCodeGenArgs to members

This patch promotes `ParseLangArgs` and `ParseCodeGenArgs` to members of `CompilerInvocation`. That will be useful in the following patch D94682, where we need to access protected members of `LangOptions` and `CodeGenOptions`. Both of those classes already have `friend CompilerInvocation`.

This is cleaner than keeping those functions freestanding and having to specify the exact signature of both in extra `friend` declarations.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94681

show more ...

[clang][cli] NFC: Parse some LangOpts after the defaults are set

This patch ensures we only parse the necessary options before calling `setLangDefaults` (explained in D94678).

Because neither `Lang

[clang][cli] NFC: Parse some LangOpts after the defaults are set

This patch ensures we only parse the necessary options before calling `setLangDefaults` (explained in D94678).

Because neither `LangOpts.CFProtectionBranch` nor `LangOpts.SYCLIsDevice` are used in `setLangDefaults`, this is a NFC.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94680

show more ...

[clang][cli] NFC: Add PIE parsing for precompiled input and IR

This patch effectively reverts a small part of D83979.

When we stop parsing `LangOpts` unconditionally in `parseSimpleArgs` (above the

[clang][cli] NFC: Add PIE parsing for precompiled input and IR

This patch effectively reverts a small part of D83979.

When we stop parsing `LangOpts` unconditionally in `parseSimpleArgs` (above the diff) and move them back to `ParseLangArgs` (called in `else` branch) in D94682, `LangOpts.PIE` would never get parsed in this `if` branch. This patch ensures this doesn't happen.

Right now, this causes `LangOpts.PIE` to be parsed twice, but that will be immediately corrected in D94682.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94679

show more ...

[clang][cli] Parse & generate options necessary for LangOptions defaults manually

It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be condi

[clang][cli] Parse & generate options necessary for LangOptions defaults manually

It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).

D94682 moves the parsing of marshalled `LangOpts` from `parseSimpleArgs` back to `ParseLangArgs`.

We need to parse marshalled `LangOpts` **after** `ParseLangArgs` calls `setLangDefaults`. This will enable future patches, where values of some `LangOpts` depend on the defaults.

However, two language options (`-finclude-default-header` and `-fdeclare-opencl-builtins`) need to be parsed **before** `ParseLangArgs` calls `setLangDefaults`, because they are necessary for setting up OpenCL defaults correctly.
This patch implements this by removing their marshalling info and manually parsing (and generating) them exactly where necessary.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94678

show more ...

[clang][cli] Specify KeyPath prefixes via TableGen classes

It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only wh

[clang][cli] Specify KeyPath prefixes via TableGen classes

It turns out we need to handle `LangOptions` separately from the rest of the options. `LangOptions` used to be conditionally parsed only when `!(DashX.getFormat() == InputKind::Precompiled || DashX.getLanguage() == Language::LLVM_IR)` and we need to restore this order (for more info, see D94682).

We could do this similarly to how `DiagnosticOptions` are handled: via a counterpart to the `IsDiag` mix-in (e.g. `IsLang`). These mix-ins would prefix the option key path with the appropriate `CompilerInvocation::XxxOpts` member. However, this solution would be problematic, as we'd now have two kinds of options (`Lang` and `Diag`) with seemingly incomplete key paths in the same file. To understand what `CompilerInvocation` member an option affects, one would need to read the whole option definition and notice the `IsDiag` or `IsLang` class.

Instead, this patch introduces more robust way to handle different kinds of options separately: via the `KeyPathAndMacroPrefix` class. We have one specialization of that class per `CompilerInvocation` member (e.g. `LangOpts`, `DiagnosticOpts`, etc.). Now, instead of specifying a key path with `"LangOpts->UndefPrefixes"`, we use `LangOpts<"UndefPrefixes">`. This keeps the readability intact (you don't have to look for the `IsLang` mix-in, the key path is complete on its own) and allows us to specify a custom macro prefix within `LangOpts`.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94676

show more ...

[clang][cli] NFC: Decrease the scope of ParseCodeGenArgs parameters

Instead of passing the whole `TargetOptions` and `FrontendOptions` to `ParseCodeGenArgs` give it only the necessary members.
This

[clang][cli] NFC: Decrease the scope of ParseCodeGenArgs parameters

Instead of passing the whole `TargetOptions` and `FrontendOptions` to `ParseCodeGenArgs` give it only the necessary members.
This makes tracking the dependencies between various parsers and option groups easier.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94675

show more ...

[clang][cli] NFC: Decrease the scope of ParseLangArgs parameters

Instead of passing the whole `TargetOptions` and `PreprocessorOptions` to `ParseLangArgs` give it only the necessary members.
This ma

[clang][cli] NFC: Decrease the scope of ParseLangArgs parameters

Instead of passing the whole `TargetOptions` and `PreprocessorOptions` to `ParseLangArgs` give it only the necessary members.
This makes tracking the dependencies between various parsers and option groups easier.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D94674

show more ...

[clang][cli] Port more CodeGenOptions to marshalling infrastructure

Leveraging the recently added TableGen constructs (ShouldParseIf and MarshallingInfoStringInt) to shift from manual command line p

[clang][cli] Port more CodeGenOptions to marshalling infrastructure

Leveraging the recently added TableGen constructs (ShouldParseIf and MarshallingInfoStringInt) to shift from manual command line parsing to automatic TableGen-driver marshalling.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D94488

show more ...

[clang][cli] NFC: Remove SSPBufferSize assignment

This should've been part of D84669, but got overlooked. Removing the assignment is NFC, as it's also done by the marshalling infrastructure for the

[clang][cli] NFC: Remove SSPBufferSize assignment

This should've been part of D84669, but got overlooked. Removing the assignment is NFC, as it's also done by the marshalling infrastructure for the stack_protector_buffer_size option.

Reviewed By: dexonsmith in D94488

show more ...

[Frontend] Add pragma align natural and sort out pragma pack stack effect

- Implemente the natural align for XL on AIX
- Sort out pragma pack stack effect
- Add -fxl-pragma-stack option to enable XL

[Frontend] Add pragma align natural and sort out pragma pack stack effect

- Implemente the natural align for XL on AIX
- Sort out pragma pack stack effect
- Add -fxl-pragma-stack option to enable XL on AIX pragma stack effect

Differential Revision: https://reviews.llvm.org/D87702

show more ...