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
Fix layering between `CompilerInstance::createDefaultOutputFile` and the
two versions of `createOutputFile`.
- Add missing configuration flags to `createDefaultOutputFile` so that
GeneratePCHAction and GenerateModuleFromModuleMapAction can use it.
They previously promised that temporary files were turned on; now
`createDefaultOutputFile` handles that logic.
- Lift the logic handling `InFile` and `Extension` to
`createDefaultOutputFile`, since it's only the callers of that
function that are using it.
- Rename the deeper of the two `createOutputFile`s to
`createOutputFileImpl` and make it private to `CompilerInstance` (to
prove that no one else is using it).
- Sink the logic for adding to `CompilerInstance::OutputFiles` down to
`createOutputFileImpl`, allowing two "optional" (but always used)
`std::string*` out parameters to be removed.
- Instead of passing a `std::error_code` out parameter into
`createOutputFileImpl`, have it return `Expected<>`.
- As a drive-by, inline `CompilerInstance::addOutputFile` into its only
caller, `createOutputFileImpl`.
Clean layering makes it easier for a future commit to extract
`createOutputFileImpl` out of `CompilerInstance`.
Differential Revision: https://reviews.llvm.org/D93248
Add a new `raw_pwrite_ostream` variant, `buffer_unique_ostream`, which
is like `buffer_ostream` but with unique ownership of the stream it's
wrapping. Use this in CompilerInstance to simplify the ownership of
non-seeking output streams, avoiding logic sprawled around to deal with
them specially.
This also simplifies future work to encapsulate output files in a
different class.
Differential Revision: https://reviews.llvm.org/D93260
Found this memory leak in `CompilerInstance::setVerboseOutputStream` by
inspection; it looks like this wasn't previously exercised, since it was
never called twice.
Differential Revision: https://reviews.llvm.org/D93249
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
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
Clarify that `PrecompiledPreamble::CanReuse` requires non-null arguments
for `VFS` and `MainFileBuffer`, taking them by reference instead of by
pointer.
Differential Revision: https://reviews.llvm.org/D91297
Refactor the duplicated canonicalize-path logic in `FileCollector` and
`ModulesDependencyCollector` into a new utility called
`PathCanonicalizer` that's shared. This popped up when tracking down a
bug common to both in https://reviews.llvm.org/D95202.
As drive-bys, update a few names and comments to better reflect the
effect of the code, delay removal of `..`s to avoid an unnecessary extra
string copy, and leave behind a couple of FIXMEs for future
consideration.
Differential Revision: https://reviews.llvm.org/D95279
Currently, there is some refactoring needed in existing interface of OpenCL option
settings to support OpenCL C 3.0. The problem is that OpenCL extensions and features
are not only determined by the target platform but also by the OpenCL version.
Also, there are core extensions/features which are supported unconditionally in
specific OpenCL C version. In fact, these rules are not being followed for all targets.
For example, there are some targets (as nvptx and r600) which don't support
OpenCL C 2.0 core features (nvptx.languageOptsOpenCL.cl, r600.languageOptsOpenCL.cl).
After the change there will be explicit differentiation between optional core and core
OpenCL features which allows giving diagnostics if target doesn't support any of
necessary core features for specific OpenCL version.
This patch also eliminates `OpenCLOptions` instance duplication from `TargetOptions`.
`OpenCLOptions` instance should take place in `Sema` as it's going to be modified
during parsing. Removing this duplication will also allow to generally simplify
`OpenCLOptions` class for parsing purposes.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D92277
This change adds an AssemblerInvocation class, similar to the
CompilerInvocation class. It can be used to invoke cc1as directly.
The project I'm working on wants to compile Clang and use it as a static
library. For that to work, there must be a way to invoke the assembler
programmatically, using the same arguments as you would otherwise pass
to cc1as.
Differential Revision: https://reviews.llvm.org/D63852
Rather than reimplement, use a `using` declaration to bring in
`SmallVectorImpl<char>`'s assign and append implementations in
`SmallString`.
The `SmallString` versions were missing reference invalidation
assertions from `SmallVector`. This patch also fixes a bug in
`llvm::FileCollector::addFileImpl`, which was a copy/paste from
`clang::ModuleDependencyCollector::copyToRoot`, both caught by the
no-longer-skipped assertions.
As a drive-by, this also sinks the `const SmallVectorImpl&` versions of
these methods down into `SmallVectorImpl`, since I imagine they'd be
useful elsewhere.
Differential Revision: https://reviews.llvm.org/D95202
This addresses an issue with how the PCH preable works, specifically:
1. When using a PCH/preamble the module hash changes and a different cache directory is used
2. When the preamble is used, PCH & PCM validation is disabled.
Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date.
rdar://72611253
Differential Revision: https://reviews.llvm.org/D95159
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
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
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
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
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
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
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
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
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
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
This patch removes the -f[no-]trapping-math flags from the -cc1 command line. These flags are ignored in the command line parser and their semantics is fully handled by -ffp-exception-mode.
This patch does not remove -f[no-]trapping-math from the driver command line. The driver flags are being used and do affect compilation.
Reviewed By: dexonsmith, SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D93395
This reverts commit 8e3e148c
This commit fixes two issues with the original patch:
* The sanitizer build bot reported an uninitialized value. This was caused by normalizeStringIntegral not returning None on failure.
* Some build bots complained about inaccessible keypaths. To mitigate that, "this->" was added back to the keypath to restore the previous behavior.
GCC r218397 "x86-64: Optimize access to globals in PIE with copy reloc" made
-fpie code emit R_X86_64_PC32 to reference external data symbols by default.
Clang adopted -mpie-copy-relocations D19996 as a flexible alternative.
The name -mpie-copy-relocations can be improved [1] and does not capture the
idea that this option can apply to -fno-pic and -fpic [2], so this patch
introduces -f[no-]direct-access-external-data and makes -mpie-copy-relocations
their aliases for compatibility.
[1]
For
```
extern int var;
int get() { return var; }
```
if var is defined in another translation unit in the link unit, there is no copy
relocation.
[2]
-fno-pic -fno-direct-access-external-data is useful to avoid copy relocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65888
If a shared object is linked with -Bsymbolic or --dynamic-list and exports a
data symbol, normally the data symbol cannot be accessed by -fno-pic code
(because by default an absolute relocation is produced which will lead to a copy
relocation). -fno-direct-access-external-data can prevent copy relocations.
-fpic -fdirect-access-external-data can avoid GOT indirection. This is like the
undefined counterpart of -fno-semantic-interposition. However, the user should
define var in another translation unit and link with -Bsymbolic or
--dynamic-list, otherwise the linker will error in a -shared link. Generally
the user has better tools for their goal but I want to mention that this
combination is valid.
On COFF, the behavior is like always -fdirect-access-external-data.
`__declspec(dllimport)` is needed to enable indirect access.
There is currently no plan to affect non-ELF behaviors or -fpic behaviors.
-fno-pic -fno-direct-access-external-data will be implemented in the subsequent patch.
GCC feature request https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Reviewed By: tmsriram
Differential Revision: https://reviews.llvm.org/D92633
@ikudrin enabled support for dwarf64 in D87011. Adding a clang flag so it can be used through that compilation pass.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D90507
This patch introduces additional infrastructure necessary to accommodate DiagnosticOptions.
DiagnosticOptions are unique in that they are parsed by the same function in cc1 AND in the Clang driver. The call to the parsing function from the driver occurs early on in the compilation process, where no proper DiagnosticEngine exists, because the diagnostic options (passed through command line) are not known yet.
To preserve the current behavior, we need to be able to selectively parse:
* all options (for -cc1),
* only diagnostic options (for driver).
This patch achieves that in the following way:
* new MacroPrefix field is added to the Option TableGen class,
* new IsDiag TableGen mixin sets MacroPrefix to "DIAG_",
* TableGen backend serializes option records into a macro with the prefix,
* CompilerInvocation parse/generate methods define the [DIAG_]OPTION_WITH_MARSHALLING macros to handle diagnostic options separately.
Depends on D93700, D93701 & D93702.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D84673
Hans Wennborg