[mlir][acc] Report independent loops not parallelized due to unstructured control flow (#230066)
An independent acc loop whose body has unstructured control flow (for
example a backward GOTO) cannot be represented as a structured loop, so
it is executed sequentially. This happened silently: no remark was
emitted for the loop, and the user only saw a serial kernel without a
reason.
Emit a remark for such loops stating that they are not parallelized
because their control flow could not be represented as a structured
loop. This lets users identify loops that are asserted parallel but run
sequentially.
Co-Authored-By: Claude
[clang][CUDA] Perform lvalue-to-rvalue conversion on `__cluster_dims__` attribute arguments (#227998)
A `ConstantExpr` with an lvalue subexpression should always have an
lvalue APValue result.
[libc] Fail configure if requested linting cannot run (#231001)
If linting was requested but could not run, CMake previously disabled it
with a warning and generated an empty libc-lint target.
Change these conditions to FATAL_ERROR so misconfigurations fail early:
* Compiler is not Clang
* clang-tidy is not found
* Auto-discovered clang-tidy has a mismatched major version
If LLVM_LIBC_CLANG_TIDY is set explicitly, treat version mismatches as a
warning instead of an error.
Document the configure requirements in code_style.md.
Assisted-by: Automated tooling, human reviewed.
devel/electron{41,42,43,44}: Add AVX512 option to support older CPUs
Builds on older CPUs without AVX512 instructions support fail with the
following error:
In file included from ../../third_party/skia/modules/skcms/src/skcms_TransformSkx.cc:53:
../../third_party/skia/modules/skcms/src/Transform_inl.h:152:15: error: always_inline function '_mm512_cvtph_ps' requires target feature 'avx512f', but would be inlined into function 'F_from_Half' that is compiled without support for 'avx512f'
152 | return (F)_mm512_cvtph_ps((__m256i)half);
Add AVX512 option, which is ON by default (status quo). Users can set
the option to OFF to build on older hardware.
PR: 299208
Reported by: Hiroo Ono <hiroo.ono+freebsd at gmail.com>
Tested by: Hiroo Ono <hiroo.ono+freebsd at gmail.com>
devel/electron{41,42,43,44}: Add AVX512 option to support older CPUs
Builds on older CPUs without AVX512 instructions support fail with the
following error:
In file included from ../../third_party/skia/modules/skcms/src/skcms_TransformSkx.cc:53:
../../third_party/skia/modules/skcms/src/Transform_inl.h:152:15: error: always_inline function '_mm512_cvtph_ps' requires target feature 'avx512f', but would be inlined into function 'F_from_Half' that is compiled without support for 'avx512f'
152 | return (F)_mm512_cvtph_ps((__m256i)half);
Add AVX512 option, which is ON by default (status quo). Users can set
the option to OFF to build on older hardware.
PR: 299208
Reported by: Hiroo Ono <hiroo.ono+freebsd at gmail.com>
Tested by: Hiroo Ono <hiroo.ono+freebsd at gmail.com>
[clang][NVPTX] Emit !atomic.ignore.denormal.mode for CUDA atomics (#217587)
CUDA's atomicAdd() family is defined in terms of PTX atom.add, whose
denormal behavior is fixed by the hardware. Without any annotation the
backend has to assume the function's denormal mode must be honored and
expands these into CAS loops whenever the two disagree. Mark them with
!atomic.ignore.denormal.mode so the native instruction is used.
That covers the __nvvm_atom_*_add_gen_f builtins that atomicAdd(),
atomicAdd_block() and atomicAdd_system() are written in terms of, plus
C11/C++11 atomics under -fatomic-ignore-denormal-mode and the
[[clang::atomic(ignore_denormal_mode)]] attribute, which requires
teaching the NVPTX target about AtomicOptions.
The condition for when the metadata is meaningful is now shared with the
AMDGPU and SPIR-V targets in addAtomicIgnoreDenormalModeMetadata(). It
takes an AllowHalf flag because whether f16 denormals are observable is
target specific: PTX exposes no FTZ control for f16 operations, so
atom.add.f16 never flushes and the opt-in is meaningful there, whereas
[4 lines not shown]
