[Clang][Driver] Parallelize device cc1 jobs for offload arches
[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.
18221 mdb: 'htable.ht_pfn' may be used uninitialized
Reviewed by: Jason King <jason.brian.king+illumos at gmail.com>
Reviewed by: Gordon Ross <gordon.w.ross at gmail.com>
Approved by: Dan McDonald <danmcd at edgecast.io>
[AMDGPU] Make `(v2i32 (trunc v2i64:$a))` legal (#207761)
`performShlCombine` introduced a `v2i32 truncate x:v2i64`. This
pattern is not legal, and is normally expanded by the legalizer.
However, since the combine is done after legalization the illegal
pattern remains.
This happens on `gfx1251` since it has legal `shl v2i64` instructions
(due to `PackedU64Ops`).
This patch introduces a legal pattern for `v2i32 truncate x:v2i64`.
AMDGPU/GlobalISel: Switch RegBankLegalize lowering to extended LLTs
Stop using LLT::scalar for lowering in AMDGPURegBankLegalizeHelper
Affects integer lowering code for RegBankLLTMappingApplyID and
custom cpp for LoweringMethodID.
math/scilab-toolbox-swt: fix build
Fixed by adding some libraries to NO_SHLIB_REQUIRES_GLOB in math/scilab.
Unbroken, but still deprecated as nobody noticed that it was broken.
Approved-by: no maintainer
AMDGPU/GlobalISel: Switch legalizer custom lowering to extended LLTs
Stop using LLT::scalar in custom lowering in AMDGPULegalizerInfo.
The exception is S1 since it seems to work fine.
Does not change legalizer actions. In general this is intended as a
mechanical step in amdgpu's switch to extended LLTs, just try to
avoid LLT::scalar in instructions generated after IRtranslator,
since it seems like a step in the right direction. Some tests remove
-global-isel-abort=2 since GIM_SwitchType no longer fails on
LLT::scalar. Exposes a couple of new failures with 16bit bitcast.
AMDGPU/GlobalISel: Switch CallLowering to extended LLTs
Stop using LLT::scalar for argument lowering in AMDGPUCallLowering.
Mostly straightforward, worth noting that some places now require
a bitcast between integer and float.
AMDGPU/GlobalISel: Switch to extended LLTs (#207419)
IRtranslator now translates bfloat. Switch tablegen to use extendedLLTs.
Around 300 regression tests fail to inst-select because GIM_SwitchType
does not accept LLT::scalar. Around 100 mir inst select tests had input
updated to i32/f32 and select successfully. Then there are 24 various
crashes, mostly combiner or machine-verifier, those tests are disabled.
Most problems come from mixing s32 with i32/f32 and the way operator==
works with extendedLLTs compared to GIM_SwitchType.
In general, for inst-select fixes, I think it would be best to avoid
explicit use of LLT::scalar in lowering to avoid mixing it with
LLT::integer/LLT::float See inst-select-extendedLLTs.mir and
inst-select-extendedLLTs-err.mir.
clang/AMDGPU: Merge toolchain subclasses (#204863)
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
[8 lines not shown]
[clang][Preprocessor] Fix expansion locations for feature-like builtin macros (#207130)
Fixes #196067.
This patch fixes the expansion locations of synthesized tokens produced
by
feature-like builtin macros such as `__has_builtin(...)`.
Feature-like builtin macros lex past the macro name while evaluating
their
arguments. `ExpandBuiltinMacro()` used the final `Tok` location as both
the
expansion start and end when creating the synthesized result token, so
`__has_builtin(...)` results were anchored at the closing paren rather
than the
builtin macro invocation.
Fix by saving the macro-name location before argument parsing and using
it as
[15 lines not shown]
Update porter handbook: Quarterly and Latest Ports Branches
Summary: By default, the pkg ports repo is now "FreeBSD-ports".
Reviewers: bcr
Differential Revision: https://reviews.freebsd.org/D54574
[LangRef] State that the memory model is an axiomatic one
Currently, one could read large parts of the memory model without learning for
sure whether it is meant as an operational model that describes how individual
operations change some notion of state or if it is an axiomatic model (like the
C++ memory model) that lists constraints that a candidate execution must
satisfy to be allowed.
While the description of what a read returns sounds somewhat operational,
aspects like the definition of fence instructions, the monotonic modification
order, and the total order of sequentially consistent operations place it in
the realm of axiomatic models.
This is an attempt to make the nature of the model more explicit (and maybe a
place to discuss the nature of the model), as suggested by RalfJung in the
reviews for #204329.
