OffloadArch was a flat enum that hand-duplicated every AMDGPU and NVPTX
target, plus a few edge cases. This was yet another place that needed
updating every time a new target is added, which should now be avoided.
Replace with a tagged union-like scheme.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply@anthropic.com>
The new offload driver packages multi-architecture bitcode in LLVM
offload binaries. A later `--hip-link --offload-device-only`
invocation treated these `.bc` inputs as host LLVM IR and dropped
them before linking.
Pass these inputs directly to clang-linker-wrapper when producing a
device fat binary. The wrapper can then extract and link each
requested GPU architecture.
Users and tools sometimes need to know which C++ standard library Clang
selected, and which include directories the driver added for it. Today
they have to inspect verbose or `-###` output.
Add options to print this information directly:
`--print-cxx-stdlib`
`--print-cxx-stdlib-include-dirs`
For MSVC targets, the default printed library is `msvcstl`. Explicit
`-stdlib=` values are still reported as requested. The include-dir query
reuses toolchain logic, including the MSVC STL include path for the
default MSVC case.
[Clang][Driver] Parallelize device cc1 jobs for offload arches
Large offload builds can target many device architectures. A common
ROCm build can target around ten `--offload-arch=` values. For a large
single translation unit, the offload device cc1 work before
clang-linker-wrapper can become a build-time bottleneck. Those
per-architecture jobs are independent, but the driver ran them serially,
so `--offload-jobs=` only helped the later wrapper work.
Borrow the parallel job mechanism used by clang-linker-wrapper for the
pre-wrapper device cc1 jobs. Device job construction marks eligible
compile and backend jobs with an offload parallel group. The generic
executor only consumes that opt-in metadata for adjacent device jobs
with distinct bound architectures.
The parallel path is disabled for driver-side output modes and callbacks
so existing serial output handling is preserved. This is NFC for
non-offload compilation.
Simplify the toolchain implementations by collapsing
them into one. Previously we had a confusing split. The
AMDGPUToolChain base class implemented much of the base
support. It was subclassed by ROCMToolChain, which would
have been more accurately described as the offloading subclass.
That was further subclassed into HIP and OpenMP specific subclasses.
Deleting those two is the important part of this change. There was
code duplication, and features arbitrarily handled in one but not
the other. The offload kind is passed in almost everywhere if you
really need to know the original language. However, I consider
this an antifeature, and it is really poor QoI to have the HIP
and OpenMP toolchains behave differently in any way. The platform
should be consistent and the driver behaviors should not depend
on the language.
There is additional mess in the handling of spirv, which this
only partially addresses. There are two different spirv toolchain
paths, which for some reason is keyed off of the amdhsa OS, which
is not the property that should change this. I think it will
ultimately be simplier to just merge all spirv handling into HIPSPV.
The copy-paste machine did most of the work here, and I manually
applied some logical fixups that became apparent after the merge.
Co-Authored-By: Claude <noreply@anthropic.com>
Move towards using the triple for representing incompatible
ISA changes. Use the subarch field to represent the various
incompatible cases. Previously we pretended a single triple arch
was universally compatible, and only distinguished by function
level subtargets. Move towards using distinct triples to enable
more sophisticated toolchain handling in the future, like proper
runtime library linking.
Introduce a new subarch per unique ISA, but also introduce
"major subarches" which are compatible by a set of covered
minor ISA versions. These map to the existing generic targets.
There are a few placeholder subarch entries, which currently
have missing backing generic arches for codegen.
This should be the preferred triple arch name going forward,
but is treated as an alias of amdgcn. This does not yet change
clang to emit the new triples.
Part of #154925
When -marm64x is used during the assembly phase, construct jobs for both
native and EC targets and merge their outputs using llvm-objcopy.
Allow passing ArchName to computeTargetTriple on non-Darwin targets to
enable BindArchAction on other platforms. Additionally, allow passing
multiple inputs to ObjcopyJobAction and use this capability to construct
ARM64X merge jobs.
This adds diagnostic groups, command-line options, a language option,
and various other things required to support `-std=c++2d`. I haven’t
touched e.g. clang-tidy or clang-format, as I’m not really familiar w/
either. This is only meant to add the most necessary parts to support
C++29 mode.
I grepped for `CPlusPlus26`/`C++26`/`C++2c` and updated all places I
could find where we need to handle every language mode in some way or
another.
This patch is roughly based on b763d6a4ed.
1723b7a301 added a frontend check that rejects C inputs when SYCL mode
is active (since SYCL requires C++). The stdin path in BuildInputs
hardcoded TY_C regardless of driver mode, so `-fsycl -dM -E -` would
pass -x c to cc1 and trigger the new diagnostic.
Fix: use TY_CXX for stdin when IsSYCL.
Also, upstream a downstream test that fails due to 1723b7a301.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
The directory name ScalableStaticAnalysisFramework produces build paths
that exceed Windows' MAX_PATH limit (260 chars) on downstream CI bots.
The clang-ssaf-format / clang-ssaf-linker tool names and SSAF-prefixed
source filenames are unchanged.
Assisted-By: Claude Opus 4.7
---------
Co-authored-by: Aviral Goel <goel.aviral@gmail.com>
Co-authored-by: Aviral Goel <aviralg@users.noreply.github.com>
Change BoundArch arguments in the clang driver from StringRef (or
sometimes const char*) to a dedicated struct type that contains both
the architecture string and a parsed OffloadArch enum field. In the
future it may be useful to contain other feature bits here.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary:
https://github.com/llvm/llvm-project/pull/201457 changed the default for
all targets. Even though the old offload driver is getting removed soon
we shouldn't break it for the LLVM23 release. This simply reverts to the
original behavior, the old driver builds its jobs manually so we can
just turn off this one specific case unless the user forced it.
Start using the effective triple instead of the raw toolchain triple.
For the moment this is NFC, but will change when new uses of the subarch
field are introduced.
Several call sites pass `expr.str()` to parameters of type `const
llvm::Twine &`, forcing a throwaway heap std::string that is immediately
rewrapped into a Twine. Drop the `.str()` and let Twine accept the
StringRef/concatenation directly.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This fixes -Xopenmp-target / -Xarch for arbitrary arguments. HIP and
OpenMP had cargo-cult broken implementations of TranslateArgs, which called the
host toolchain's implementation, and then special case transferred either
-march or -mcpu to the device argument list. The respective device forwarding
flags should work for any argument, not just this one. The main feature that
needs to be preserved is the shared filtering of unsupported sanitizers to
degrade them into warnings.
Most of the changes here are dealing with fallout observed when
the host target is darwin. The darwin toolchain happens to have
some hacky statefulness tracking the compile target version, which
gets written and rewritten on argument parsing. To maintain this hack,
there are a few unused calls to getArgsForToolChain; start passing
OFK_Host to these so the offload toolchains don't get confused and think
they're in a non-offload context.
Avoid littering calls to normalize around by ensuring toolchains
always use a normalized triple. The test changes are due to
inconsistencies in the behavior of the triple APIs. If the arch name
is empty, normalize leaves it unchanged. If the triple is archname--,
normalize will expand the empty groups to be unknown. setArchName
will introduce the empty groups, which occurs in some of the triple
modifying driver path (mostly the handling of the endianness -m flags).
Driver is still holding onto a raw, unnormalized string triple but
leave that for a later cleanup.
Co-authored-by: Claude Sonnet 4 <noreply@anthropic.com>
Summary:
Previously we had several layers of if conditions that functionally
amounted to pretending like we were in LTO-mode. The previous changes
moved the LTO settings into the toolchain so we can now override it for
our offloading toolchains. This allows us to respect the LTO mode, where
previously there was no way to override it.
The main artifact of this PR should be trimming up the massive if
statement.
Some slight by-products on the old-driver path, but this can be
recovered with `-fno-offload-lto` and the old driver should be deleted
in a few months anyways.
This patch is to rename ClangExecutable to DriverExecutable and
getClangProgramPath to getDriverProgramPath. This makes the
name more neutral and less confusing when used in flang.
Summary:
Currently, the LTO mode is a property of the Driver, which makes sense
because it is used to set up phases. However, we currently have `-flto`
and `-foffload-lto`, which is a split that doesn't fully work with the
full context of a heterogenous compilation as it is 'all-or-nothing'.
This PR seeks to be mostly NFC for now, just moving the queries to a
per-toolchain interface rather than the static driver mode setting we
have right now. The *single* use of this before ToolChains are created
is for the Webassembly toolchain to set an include path. This is now
just a direct check on the flag, which is consistent. In the future they
could shift to fat LTO objects as well.
The main goal for the PR is to allow the GPU / Offloading toolchains to
specify their "real" LTO behavior. Right now SPIR-V and AMDGCN both
default to LTO, but rather than re-use the LTO handling we hack through
the driver phases to override it. Allowing this split would let us
heavily simplify this logic.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
With this, Standard library modules are always precompiled as the
primary output of their `-cc1` invocation, instead of being produced as
a byproduct of compiling the Standard library modules to object files.
This also keeps Standard library module precompilation independent of
the final phase specified on the command line, so importing them keep
working under `-fsyntax-only` (and other command-line options that
specify the final phase).
This also makes the Standard library module precompilation independent
of the `-o` flag, so that a command like `clang -std=c++23
-fmodules-driver main.cpp -o main` no longer redirects the Standard
library module outputs to 'main', breaking the compilation.
Adds the version- and target-specific path
../lib/clang/<version>/finclude/flang/<target>
to the intrinsic module search path in addition to
../finclude/flang
with the former taking precedence if a module file should exist in both.
The version/target-specific path is added by the driver by passing
`-fintrinsic-modules-path` to the `-fc1` invocation. This is consistent
with gfortran and the usual pattern that the driver resolves paths into
the resource path, not the frontend.
This PR adds nothing into that directory, which will be done in #171515.
Extracted out of #171515 as requested by
https://github.com/llvm/llvm-project/pull/171515#pullrequestreview-4179212219
---------
Co-authored-by: Tarun Prabhu <tarun@lanl.gov>
Summary:
This is currently rejected in two places, the toolchain creation and the
target itself. For the target we just permit it in the same way we alloe
things like 'amdhsa'. For the driver, the current handling just assumed
everything with 'vulkan' was HLSL. This shouldn't be true so we check
the source file type, and only push through actual HLSL files.
This is intended to more canonically support the 'CLSPV' target that
google has.
If `--target` is specified it should take precedence over `OBJECT_MODE`.
This is important, for example, for lit tests which want to specify an
explicitly 32-bit or 64-bit triple on AIX, or they may get the wrong bit
mode depending on the environment they run in.
The offload case is building a fresh filepath and there's no file
extension to replace. Just directly append the file extension to avoid
clobbering part of the path name if the triple contains a period.
Avoids confusing test updates in future triple patch.
This reverts #193857 and relands #193312.
This adds basic support for explicit C++ named module builds, managed
natively by the Clang driver, including support for use of the Standard
library modules. This follows #187606, which adds the same for Clang
modules.
Current limitations:
- Standard library modules are still compiled to object files instead of
using the provided shared library. (This will be addressed in a
follow-up soon.)
- Caching is not supported yet (but likely to be added during the
upcoming GSoC cycle).
- Importing C++ standard library modules into Clang modules is not
supported (and not expected in the near term).
RFC:
https://discourse.llvm.org/t/rfc-modules-support-simple-c-20-modules-use-from-the-clang-driver-without-a-build-system
This reverts #193677 and relands #193312.
This adds basic support for explicit C++ named module builds, managed
natively by the Clang driver, including support for use of the Standard
library modules. This follows #187606, which adds the same for Clang
modules.
Current limitations:
- Standard library modules are still compiled to object files instead of
using the provided shared library. (This will be addressed in a
follow-up soon.)
- Caching is not supported yet (but likely to be added during the
upcoming GSoC cycle).
- Importing C++ standard library modules into Clang modules is not
supported (and not expected in the near term).
RFC:
https://discourse.llvm.org/t/rfc-modules-support-simple-c-20-modules-use-from-the-clang-driver-without-a-build-system
This patch adds basic support for explicit C++ named module builds,
managed natively by the Clang driver, including support for use of the
Standard library modules.
This follows #187606, which adds the same for Clang modules.
Current limitations:
- Standard library modules are still compiled to object files instead of
using the provided shared library. (This will be addressed in a
follow-up soon.)
- Caching is not supported yet (but likely to be added during the
upcoming GSoC cycle).
- Importing C++ standard library modules into Clang modules is not
supported (and not expected in the near term).
RFC:
https://discourse.llvm.org/t/rfc-modules-support-simple-c-20-modules-use-from-the-clang-driver-without-a-build-system
OpenASIP (ex. TCE*) is a special target which has only a stub target
definition in the LLVM side that has resided in LLVM for over 15 years.
I'm the original contributors of this stub.
Due to needing various other patches to LLVM that were not nicely
upstreamable, the upstream TCE target defs have long been unupdated.
However, with the recent changes to the vectorization types etc. I
managed to minimize the required LLVM TCE patch to this one and with
this patch OpenASIP can be (finally!) used without a patched LLVM for
VLIW/TTA customization. RISC-V operation set customization still
requires a patch to polish and upstream (TBD).
This patch:
* Introduces a 64b variant of an OpenASIP target.
* Unifies the datalayouts of the different target variants to make it
compatible with OpenASIP v2.2 and above.
* Updates the OpenCL address space IDs to be compatible with the latest
PoCL backends.
* Implements Triple::computeDataLayout() for completeness.
The patch is very unintrusive and I'd love to backport it in the LLVM 22
release as well.
[*] More info:
https://blog.llvm.org/2010/06/tce-project-co-design-of-application.htmlhttps://openasip.org
The actual backends for the customized processors are generated on the
fly with a backend generator of the OpenASIP project based on a target
definition file and loaded as plugins to the LLVM framework. This
mechanism enables fast "design space exploration" of
application-specific processors designed with the toolset as only a
small part of the compiler has to be regenerated for new design
candidates.
Adds support for the $arch-unknown-serenity target to the Clang front
end. This makes the compiler look for libraries and headers in the right
places, and enables some security mitigations like stack-smashing
protection and position-independent code by default.
----
A first attempt at upstreaming this patch was made
[here](https://reviews.llvm.org/D154396). I hope I fixed everything
mentioned there.
I intentionally kept `/usr/local/` in the default lookup path. I
consider it the more practical option, and I’d prefer to have the patch
merged as is and revisit the FIXME later. If this is absolutely
unacceptable to the maintainers, I will happily drop it and keep it as a
local patch until we address the underlying issue.
@MaskRay, @brad0 as you already reviewed the original patch.
---------
Co-authored-by: Daniel Bertalan <dani@danielbertalan.dev>
Co-authored-by: kleines Filmröllchen <filmroellchen@serenityos.org>
Co-authored-by: Andrew Kaster <akaster@serenityos.org>
Co-authored-by: Dan Klishch <danilklishch@gmail.com>
Clang-dxc.exe currently uses dxv by default after compiling HLSL that
targets DXIL, assuming dxv can be found. However, there is no
counterpart for SPIR-V. This PR changes clang-dxc.exe so that the DXC
driver inserts a step to run spirv-val when SPIR-V is the target. It
also accounts for whether or not the -Fo option is passed. In all cases,
spirv-val will be run, as long as the target is SPIR-V and the spirv-val
executable can be found on the PATH.
This PR also adds a new option --spirv-val-path, a counterpart to
--dxv-path, for specifying an explicit path to spirv-val.
Key differences from dxv: Unlike dxv, which validates and signs DXIL
containers and produces an output file, spirv-val is a pure validator —
it checks the SPIR-V binary and exits with a status code without
producing output. Because of this, the compile step writes directly to
-Fo and spirv-val validates the file in-place.
Additional fixes:
- Fixes a duplicate "validator not found" warning that was emitted twice
per invocation — once from BuildActions and once from isLastJob (via
GetNamedOutputPath). This was a pre-existing bug introduced by #130436
(https://github.com/llvm/llvm-project/pull/130436). Fixed by
adding a Diagnose parameter to requiresValidation so only one call site
emits the diagnostic.
- Fixes an "unused argument" warning for -Vd when targeting SPIR-V,
caused by early returns in requiresValidation before the argument was
claimed.
- Adds a new SPIRVValidation diagnostic group and
warn_drv_dxc_missing_spirv_val diagnostic for the missing spirv-val
warning.
Fixes https://github.com/llvm/llvm-project/issues/142669
Assisted by: Claude Opus 4.6
Summary:
We always accepted `--target=amdgcn--` to create IR object files but it
doesn't allow creating actual binaries without user intervention. This
is because it would fall-through to the GCC toolchain which does not
know how to handle AMGCN / AMDGPU targets. This PR just adds a single
line to handle it, which effectively allows this as a 'bare' target.
Perhaps the argument could be made that AMDGPU should not support
anything but strictly HSA because it has many assumptions in the
compiler itself, such as implicit arguments, but I feel like it is
relatively harmless to support this case if users decide they really do
not need it.
