This patch moves the CommonArgs utilities into a location visible by the
Frontend Drivers, so that the Frontend Drivers may share option parsing
code with the Compiler Driver. This is useful when the Frontend Drivers
would like to verify that their incoming options are well-formed and
also not reinvent the option parsing wheel.
We already see code in the Clang/Flang Drivers that is parsing and
verifying its incoming options. E.g. OPT_ffp_contract. This option is
parsed in the Compiler Driver, Clang Driver, and Flang Driver, all with
slightly different parsing code. It would be nice if the Frontend
Drivers were not required to duplicate this Compiler Driver code. That
way there is no/low maintenance burden on keeping all these parsing
functions in sync.
Along those lines, the Frontend Drivers will now have a useful mechanism
to verify their incoming options are well-formed. Currently, the
Frontend Drivers trust that the Compiler Driver is not passing back junk
in some cases. The Language Drivers may even accept junk with no error
at all. E.g.:
`clang -cc1 -mprefer-vector-width=junk test.c'
With this patch, we'll now be able to tighten up incomming options to
the Frontend drivers in a lightweight way.
---------
Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>
To be able to handle all of the ways the platform & deployment version
can be represented in command line flags, the Darwin toolchain holds a
type `DarwinPlatform` to help represent them. This patch simplifies the
logic by:
* reducing the amount of work done between string & version tuples
conversions
* renaming variables to reduce confusion about what target triple
information is being manipulated.
* allowing implicit transformation of macOS10.16 -> 11, there are other
places in the compiler where this happens, and it was a bit confusing
that the driver didn't do that for the cc1 call.
This is not a major refactor, but more simple & common tweaks across the
file, in hopes to make it more readable.
This option complements -funique-source-file-names and allows the user
to use a different unique identifier than the source file path.
Reviewers: teresajohnson
Reviewed By: teresajohnson
Pull Request: https://github.com/llvm/llvm-project/pull/142901
Summary:
This reverts commit 740e6aeccdb2f8eeee549ba80b15ff3d5dd3392e.
After discussions it was determined that the behavior for IR inputs
needs to be maintained at least for now. In the future we should put a
deprecation notice on this behavior. This patch keeps the old behavior
for OpenCL and IR inputs, while others will be standalone. This is good
enough for standard compile flows.
This simply moves code for diagnosing misuse of arguments `/Fo`, `/Fa`,
and `/o` from `Driver::BuildActions` into `Driver::handleArguments`,
following the intention of 740f69b.
This change better aligns with the roles of `BuildActions` and
`handleArguments`.
If the runtime path is not found (by getTargetSubDirPath()), since per
target runtime directory is enabled on AIX, we should fall back to the
target subdirectory rather than the OS subdirectory.
This PR add functionality to change `flang` command line using
environment variable `FCC_OVERRIDE_OPTIONS`. It is quite similar to what
`CCC_OVERRIDE_OPTIONS` does for clang.
The `FCC_OVERRIDE_OPTIONS` seemed like the most obvious name to me but I
am open to other ideas. The `applyOverrideOptions` now takes an extra
argument that is the name of the environment variable. Previously
`CCC_OVERRIDE_OPTIONS` was hardcoded.
Note: This relands #134985 with a fix. Original PR resulted in test fail
for msan builds.
Fix: Initialize MipsSubtarget::ProcImpl to ProcImpl::CPU::Others
[MIPS] Reland Add FeatureMSA to i6400 and i6500 cores (#134985)
- Enable 'FeatureMSA' for MIPS i6400 and i6500 cpu.
- Enable -mmsa option if mcpu is set to either i6400 or i6500
- added clang driver test to validate msa feature
- added llvm codegen test to validate msa instructions for cpu i6500 and
i6400
MIPS i6400 and i6500 cores implements and enables MSA (MIPS SIMD
ARCHITECTURE) by default.
This patch implements IR-based Profile-Guided Optimization support in
Flang through the following flags:
- `-fprofile-generate` for instrumentation-based profile generation
- `-fprofile-use=<dir>/file` for profile-guided optimization
Resolves#74216 (implements IR PGO support phase)
**Key changes:**
- Frontend flag handling aligned with Clang/GCC semantics
- Instrumentation hooks into LLVM PGO infrastructure
- LIT tests verifying:
- Instrumentation metadata generation
- Profile loading from specified path
- Branch weight attribution (IR checks)
**Tests:**
- Added gcc-flag-compatibility.f90 test module verifying:
- Flag parsing boundary conditions
- IR-level profile annotation consistency
- Profile input path normalization rules
- SPEC2006 benchmark results will be shared in comments
For details on LLVM's PGO framework, refer to [Clang PGO
Documentation](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization).
This implementation was developed by [XSCC Compiler
Team](https://github.com/orgs/OpenXiangShan/teams/xscc).
---------
Co-authored-by: ict-ql <168183727+ict-ql@users.noreply.github.com>
Co-authored-by: Tom Eccles <t@freedommail.info>
The option name to specify the path is `--libomptarget-spirv-bc-path` so
the existing error gives an invalid option name
(`--libomptarget-spirv64-bc-path`) when it can't find the file. Also the
expected file name is weird, we expect the file name to be
`libomptarget-spirv64.bc`. and use the same prefix `spirv64` to suggest
the option to the user.
Also the `nvptx` triple is `nvptx64` and the option/filename there is
just `nvptx`, so we should be consistent.
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
We currently transfer the opt level from the user clang call to CC1 args
at the end of the `ConstructJob` function, this might lead to bugs as
`ConstructJob` is a big function and we easily could add a change that
would return early from it. That would cause the opt level to not be
transferred to CC1 args and lead to wrong opt level compilation and
would be hard to spot. This PR moves the opt level to the beginning of
the function as opt level should be a direct transfer without any
problems, it also removes the redundancy where it was added 2 times
through the function.
This fixes#139614 on non-clang compilers by moving `__has_warning`
completely inside the `#if defined(__clang__)` block. This prevents a
parse failure from compilers which don't recognize `__has_warning`.
Original description:
Followup to #138741.
This adds the requested macro to silence
`-Wunnecessary-virtual-specifier` when declaring virtual anchor
functions in `final` classes, per [LLVM
policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers).
It also cleans up any remaining instances of the warning, allowing us to
stop disabling it when we build LLVM.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
Using a relative path name for the shared library name was causing the
side deck name to be incorrect. Fixed the code by using the
`replace_exentsion()` function.
Previously, when the triple is `powerpc-ibm-aix-unknown`, the driver
fails to find subdirectory `lib/powerpc-ibm-aix`.
This ensures the correct runtime path is found if the triple has the
-unknown environment component attached.
I'm working on porting ASan to Wasm/WASI targets, and this is the first
part of the change sets. I'll post runtime changes separately.
This change makes `-fsanitize=address` available for WASI target by
replicating what we do for Emscripten because they share the same memory
model.
This PR addressed issue #140748 to support XRay instrumentation on the
host side when using offloading.
It makes the following changes:
- Initializes `XRayArgs` using the processed toolchain arguments instead
of the raw input.
- Removes the current caching mechanism of `XRayArgs` in the `ToolChain`
class, as this is error-prone and potential benefits are questionable.
For reference, `SanitizierArgs`, which is constructed in a similar
manner but is much more complex, does not use any caching.
- Adds driver tests to verify that XRay flags are set correctly with
offloading and `-Xarch_host`.
lookupTarget takes StringRef and internally creates an instance of
std::string with the StringRef as part of constructing Triple, so we
don't need to create temporary instances of std::string on our own.
The behavior of -fveclib=AMDLIBM should be similar to -fveclib=libmvec.
Example - Error message for unsupported target usage should be same.
We are handling the missed cases for -fveclib=AMDLIBM and aligning it to
-fveclib=libmvec usage.
---------
Co-authored-by: Rohit Aggarwal <Rohit.Aggarwal@amd.com>
This needs to be driver level to pass an -mllvm flag to LLVM, though this may
change soon as the -mllvm flag will soon not be necessary.
Keep the flag help-hidden as the feature is under development.
This patch is part of a stack that teaches Clang to generate Key Instructions
metadata for C and C++.
RFC:
https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668
The feature is only functional in LLVM if LLVM is built with CMake flag
LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
When using `-fsanitize-trap` with a sanitizer group that doesn't support
trapping, an empty argument is passed to
`err_drv_unsupported_option_argument`. Use new `toStringWithGroups` for
the diagnostic.
`-rewrite-objc` passes `-x objective-c++-cpp-output` as input type to
the preprocessor job. This is not correct since we would be
preprocessing a preprocessed file. The correct input type is
`objective-c++`.
When using -no-integrated-cpp, before, the driver won't collapse actions
when the input was not llvm-ir
or it would collapse them too aggressively with -save-temps
The original code was checking the action type (which is IR too for
preprocessed->bc actions) instead of the action inputs.
Adds support for MSVC's undocumented `/funcoverride` flag, which marks
functions as being replaceable by the Windows kernel loader. This is
used to allow functions to be upgraded depending on the capabilities of
the current processor (e.g., the kernel can be built with the naive
implementation of a function, but that function can be replaced at boot
with one that uses SIMD instructions if the processor supports them).
For each marked function we need to generate:
* An undefined symbol named `<name>_$fo$`.
* A defined symbol `<name>_$fo_default$` that points to the `.data`
section (anywhere in the data section, it is assumed to be zero sized).
* An `/ALTERNATENAME` linker directive that points from `<name>_$fo$` to
`<name>_$fo_default$`.
This is used by the MSVC linker to generate the appropriate metadata in
the Dynamic Value Relocation Table.
Marked function must never be inlined (otherwise those inline sites
can't be replaced).
Note that I've chosen to implement this in AsmPrinter as there was no
way to create a `GlobalVariable` for `<name>_$fo$` that would result in
a symbol being emitted (as nothing consumes it and it has no
initializer). I tried to have `llvm.used` and `llvm.compiler.used` point
to it, but this didn't help.
Within LLVM I referred to this feature as "loader replaceable" as
"function override" already has a different meaning to C++ developers...
I also took the opportunity to extract the feature symbol generation
code used by both AArch64 and X86 into a common function in AsmPrinter.
Adds support for emitting Windows x64 Unwind V2 information, includes
support `/d2epilogunwind` in clang-cl.
Unwind v2 adds information about the epilogs in functions such that the
unwinder can unwind even in the middle of an epilog, without having to
disassembly the function to see what has or has not been cleaned up.
Unwind v2 requires that all epilogs are in "canonical" form:
* If there was a stack allocation (fixed or dynamic) in the prolog, then
the first instruction in the epilog must be a stack deallocation.
* Next, for each `PUSH` in the prolog there must be a corresponding
`POP` instruction in exact reverse order.
* Finally, the epilog must end with the terminator.
This change adds a pass to validate epilogs in modules that have Unwind
v2 enabled and, if they pass, emits new pseudo instructions to MC that
1) note that the function is using unwind v2 and 2) mark the start of
the epilog (this is either the first `POP` if there is one, otherwise
the terminator instruction). If a function does not meet these
requirements, it is downgraded to Unwind v1 (i.e., these new pseudo
instructions are not emitted).
Note that the unwind v2 table only marks the size of the epilog in the
"header" unwind code, but it's possible for epilogs to use different
terminator instructions thus they are not all the same size. As a work
around for this, MC will assume that all terminator instructions are
1-byte long - this still works correctly with the Windows unwinder as it
is only using the size to do a range check to see if a thread is in an
epilog or not, and since the instruction pointer will never be in the
middle of an instruction and the terminator is always at the end of an
epilog the range check will function correctly. This does mean, however,
that the "at end" optimization (where an epilog unwind code can be
elided if the last epilog is at the end of the function) can only be
used if the terminator is 1-byte long.
One other complication with the implementation is that the unwind table
for a function is emitted during streaming, however we can't calculate
the distance between an epilog and the end of the function at that time
as layout hasn't been completed yet (thus some instructions may be
relaxed). To work around this, epilog unwind codes are emitted via a
fixup. This also means that we can't pre-emptively downgrade a function
to Unwind v1 if one of these offsets is too large, so instead we raise
an error (but I've passed through the location information, so the user
will know which of their functions is problematic).
Add a new Cygwin toolchain that just goes through the motions to
initialize the Generic_GCC base properly. This allows removing some old,
almost certainly wrong hard-coded paths from Lex/InitHeaderSearch.cpp.
MSYS2 (GCC triple (arch)-pc-msys) is a fork of Cygwin (GCC triple
(arch)-pc-cygwin), and this driver can be used for either.
Add a simple test for this driver.
Currently ROCm 6.4.0 only recognize spirv64-amd-amdhsa- in bundle ID.
spirv64-amd-amdhsa-unknown causes all HIP apps compiled for amdgcnspirv
to fail.
Previously we fixed a similar issue for
amdgcn-amd-amdhsa-unknown. This patch extends that to
spirv64-amd-amdhsa-unknown.
Move the Darwin framework search path logic from
InitHeaderSearch::AddDefaultIncludePaths to
DarwinClang::AddClangSystemIncludeArgs. Add a new -internal-iframework
cc1 argument to support the tool chain adding these paths.
Now that the tool chain is adding search paths via cc1 flag, they're
only added if they exist, so the Preprocessor/cuda-macos-includes.cu
test is no longer relevant.
Change Driver/driverkit-path.c and Driver/darwin-subframeworks.c to do
-### style testing similar to the darwin-header-search and
darwin-embedded-search-paths tests. Rename darwin-subframeworks.c to
darwin-framework-search-paths.c and have it test all framework search
paths, not just SubFrameworks.
Add a unit test to validate that the myriad of search path flags result
in the expected search path list.
Fixes https://github.com/llvm/llvm-project/issues/75638
Add a new instrumentation section type `[sample-coldcov]` to
support`-fprofile-list` for sample pgo based cold function coverage.
Note that the current cold function coverage is based on sampling PGO
pipeline, which is incompatible with the existing [llvm] option(see
[PGOOptions](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/PGOOptions.h#L27-L43)),
so we can't reuse the IR-PGO(-fprofile-instrument=llvm) flag.
@fmayer introduced '-mllvm -array-bounds-pseudofn'
(https://github.com/llvm/llvm-project/pull/128977/) to make it easier to
see why crashes occurred, and to estimate with a profiler the cycles
spent on these array-bounds checks. This functionality could be usefully
generalized to other checks in future work.
This patch adds the plumbing for -fsanitize-annotate-debug-info, and
connects it to the existing array-bounds-pseudo-fn functionality i.e.,
-fsanitize-annotate-debug-info=array-bounds can be used as a replacement
for '-mllvm -array-bounds-pseudofn', though we do not yet delete the
latter.
Note: we replaced '-mllvm -array-bounds-pseudofn' in
clang/test/CodeGen/bounds-checking-debuginfo.c, because adding test
cases would modify the line numbers in the test assertions, and
therefore obscure that the test output is the same between '-mllvm
-array-bounds-pseudofn' and -fsanitize-annotate-debug-info=array-bounds.
