This adds a pyproject.toml file for packaging the clang Python bindings
as a sdist tarball and pure Python wheel packages for the clang python
bindings. It is required to move updates of the clang and libclang PyPI
packages to the LLVM monorepo. Versioning information is derived from
LLVM git tags (using hatch-vcs, which is based on setuptools_scm), so no
manual updates are needed to bump version numbers. The minimum python
version required is set to 3.10 due to cindex.py using PEP 604 union
type syntax (str | bytes | None).
The .git_archival.txt file is populated with version information needed
to get accurate version information if the bindings are installed from
an LLVM/clang source code archive. The .gitignore file is populated with
files that may get created as part of building/testing the sdist and
wheel that should not be committed to source control.
This is first step for addressing #125220, and moving publishing of the
clang and libclang PyPI packages into the LLVM monorepo.
Signed-off-by: Ryan Mast <mast.ryan@gmail.com>
Clarify how Clang-generated HIP fat binaries are registered and
unregistered with the HIP runtime, and how this interacts with global
constructors, destructors, and atexit handlers. Document that there is
no strong guarantee on ordering relative to user-defined global
ctors/dtors, recommend that HIP application developers avoid using
kernels or device variables from global ctors/dtors, and describe the
implications for HIP runtime developers (synchronization and guards in
__hipRegisterFatBinary/__hipUnregisterFatBinary). This is motivated by
questions from HIP application and runtime developers about fat binary
registration/unregistration order and its potential interference with
their own initialization and teardown code.
This way if the downstream consuming project uses zstd we make sure
they are dedup'd. This uses a new rule to make sure layering_check still
works while allowing us to augment the upstream library rules with LLVM
specific `defines`.
Previously, i16 `bswap` was lowered using multiple shift and OR
operations. This patch adds a pattern to directly lower i16 `bswap`
using the `PRMT` (permute) instruction, which is more efficient.
Additionally, the lowering of `bswap` is moved into operation
legalization, which allows for DAGCombiner to optimize the lowered code.
Fix kernel build when cl_khr_fp64 is not enabled:
opencl-c.h:13785:50: error: unknown type name 'atomic_double'
13785 | double __ovld atomic_fetch_min(volatile __global atomic_double
*, double);
opencl-c.h:13785:67: error: use of type 'double' requires cl_khr_fp64
and __opencl_c_fp64 support
13785 | double __ovld atomic_fetch_min(volatile __global atomic_double
*, double);
This is a regression introduced by 423bdb2b. Before that commit,
__opencl_c_ext_fp64_global_atomic_add was guarded by cl_khr_fp64 in
opencl-c-base.h.
This is mostly the output of a vibe coded script running on
VecFuncs.def, with a lot of manual cleanups and fixing where the
vibes were off. This is not yet wired up to anything (except for the
handful of calls which are already manually enabled). In the future
the SystemLibrary mechanism needs to be generalized to allow plugging
these sets in based on the flag.
One annoying piece is there are some name conflicts across the
libraries. Some of the libmvec functions have name collisions with some
sleef functions. I solved this by just adding a prefix to the libmvec functions.
It would probably be a good idea to add a prefix to every group. It gets ugly,
particularly since some of the sleef functions started to use a Sleef_
prefix, but mostly do not.
When running the tests on other platforms, printing the stats on all of
the passing tests makes it hard to see failure output. Therefore, this
change only prints the stats if the test actually fails.
AMDGPU requires more complex CFI rules, normally these would be
expressed with .cfi_escape, however this would make the CFI unreadable
and makes it difficult to update registers in CFI instructions (also
something AMDGPU requires).
Authored-by: Emma Pilkington <Emma.Pilkington@amd.com>
In the LoweringPrepare pass, the handling for global array destructor
lowering was mishandling the insertion point, so that if this code
needed to create a declaration for the __cxa_atexit function, that
declaration was being created in the dtor region, rather than at module
scope. This change fixes that.
PR168884 flagged compiler directives (!dir$ ...) inside OpenMP loop
constructs as errors. This caused some customer applications to fail to
compile (issue 169229).
Downgrade the error to a warning, and gracefully ignore compiler
directives when lowering loop constructs to MLIR.
Fixes https://github.com/llvm/llvm-project/issues/169229
Implement `this_cluster` like `this_group` by lowering it directly like
an intrinsic function. Use the NVVM operation to get the rank and size
information and populate the derived type.
This is currently a no op.
This will be supported for the minimal runtime in a follow up. This
allows
to improve codegen for fsanitize-recover by compiling the handlers with
[[clang::preserve_all]]. This makes sure that the caller does not need
to spill any registers. We do not expect this function to be called
frequently, so this is beneficial for code size.
SVE depends on a combination of host support and operating system
support. Sometimes those don't line up with detected host CPU name; make
sure SVE is disabled when it isn't available. Implement this for both
Windows and Linux. (We don't have a codepath for other operating
systems. If someone wants to implement this, it should be possible to
adapt fmv code from compiler-rt.)
While I'm here, also add support for detecting other Windows CPU
features.
For Windows, declare constants ourselves so the code builds on older
SDKs; we also do this in compiler-rt.
OffsetSizeAndStrideOpInterface does not specify whether it's operating
on the input or output shape and in fact different ops implement this in
different ways, which is also why SubviewOp is special cased here.
This "marked as dynamic but not really dynamic" folding is better
handled by shape inference, so just remove the bad fold.
This avoids dozens of instances of benign error messages being printed
when running the tests on e.g. Windows:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'os' has no attribute 'sysconf'
Co-authored-by: Florian Mayer <fmayer@google.com>
Previously, e.g. for TypeLoc "MyNamespace::MyClass", `node()` selects
only "MyClass" without the qualifier. With this change, it now selects
"MyNamespace::MyClass".
---------
Co-authored-by: Florian Mayer <fmayer@google.com>
This commit adds a `MockDwarfDelegate` class that can be used to control
what dwarf version is used when evaluating an expression. We also add a
simple test that shows how dwarf version can change the result of the
expression.
This fixes test errors like this, at least for a mingw target, if
building with Clang 21 instead of Clang 20, as in the CI environment:
# .---command stderr------------
# | error: 'expected-error' diagnostics seen but not expected:
# | File C:\a\llvm-mingw\llvm-mingw\llvm-project\libcxx\test\std\input.output\file.streams\c.files\gets-removed.verify.cpp Line 16: cannot initialize a parameter of type 'char *' with an lvalue of type 'const char *'
# | 1 error generated.
# `-----------------------------
# error: command failed with exit status: 1
This extra, unexpected diagnostic appears in Clang 21, since commit
9eef4d1c5fa6b1bcbbe675c14ca8301d5d346f7b ("Remove delayed typo
expressions"). Before this, we got the expected diagnostic `error: no
member named 'gets' in namespace 'std'`, with the typo correction hint
`did you mean 'puts'?`. After this change, we get the typo correction
hint `did you mean simply 'gets'?` instead. And with the typo correction
finding `::gets`, it goes on to produce a second diagnostic about
mismatched parameter for that function.
Avoid these unexpected diagnostics by passing the right type of
parameter to the gets function.
This patch add support for lowering of custom reductions to MLIR. It
also enhances the capability of the pass to automatically mark functions
as "declare target" by traversing custom reduction initializers and
combiners.
Adds an explicit include of `<cassert>` in StringTable.h rather than
relying on the one in StringRef.h. Fixes potential compile errors if
assert() was undef'ed between StringRef.h and StringTable.h inclusion.
While the infrastructure for declare target to/enter and link for
variables exists in the MLIR dialect and at the Flang level, the current
lowering from MLIR -> LLVM IR isn't in place, it's only in place for
variables that have the link clause applied.
This PR aims to extend that lowering to an initial implementation that
incorporates declare target to as well, which primarily requires changes
in the OpenMPToLLVMIRTranslation phase. However, a minor addition to the
OpenMP dialect was required to extend the declare target enumerator to
include a default None field as well.
This also requires a minor change to the Flang lowering's
MapInfoFinlization.cpp pass to alter the map type for descriptors to
deal with cases where a variable is marked declare to. Currently, when a
descriptor variable is mapped declare target to the descriptor component
can become attatched, and cannot be updated, this results in issues when
an unusual allocation range is specified (effectively an off-by X
error). The current solution is to map the descriptor always, as we
always require an up-to-date version of this data. However, this also
requires an interlinked PR that adds a more intricate type of mapping of
structures/record types that clang currently implements, to circumvent
the overwriting of the pointer in the descriptor.
3/3 required PRs to enable declare target to mapping, this PR should
pass all tests and provide an all green CI.
Co-authored-by: Raghu Maddhipatla raghu.maddhipatla@amd.com
This PR introduces a new additional type of map lowering for record
types that Clang currently supports, in which a user can map a top-level
record type and then individual members with different mapping,
effectively creating a sort of "overlapping" mapping that we attempt to
cut around.
This is currently most predominantly used in Fortran, when mapping
descriptors and there data, we map the descriptor and its data with
separate map modifiers and "cut around" the pointer data, so that wedo
not overwrite it unless the runtime deems it a neccesary action based on
its reference counting mechanism. However, it is a mechanism that will
come in handy/trigger when a user explitily maps a record type (derived
type or structure) and then explicitly maps a member with a different
map type.
These additions were predominantly in the OpenMPToLLVMIRTranslation.cpp
file and phase, however, one Flang test that checks end-to-end IR
compilation (as far as we care for now at least) was altered.
2/3 required PRs to enable declare target to mapping, should look at PR
3/3 to check for full green passes (this one will fail a number due to
some dependencies).
Co-authored-by: Raghu Maddhipatla raghu.maddhipatla@amd.com
Adds support for the `__builtin_ia32_kshiftli` and
`__builtin_ia32_kshiftri` X86 builtins.
Part of #167765
---------
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
Currently, in the following snippet, the second designated initializer
is incorrectly detected as an OBJC method expr. Fix that and a test to
make sure we don't regress.
```
Foo foo[] = {[0] = 1, [1] = 2};
```
If the expected trip count is less than the VF, the vector loop will
only execute a single iteration. When that's the case, the cost of the
middle block has the same impact as the cost of the vector loop. Include
it in isOutsideLoopWorkProfitable to avoid vectorizing when the extra
work in the middle block makes it unprofitable.
Note that isOutsideLoopWorkProfitable already scales the cost of blocks
outside the vector region, but the patch restricts accounting for the
middle block to cases where VF <= ExpectedTC, to initially catch some
worst cases and avoid regressions.
This initial version should specifically avoid unprofitable tail-folding
for loops with low trip counts after re-applying
https://github.com/llvm/llvm-project/pull/149042.
PR: https://github.com/llvm/llvm-project/pull/168949
The `AArch64AsmPrinter::emitPtrauthCheckAuthenticatedValue` method accepts
two arguments, `bool ShouldTrap` and `const MCSymbol *OnFailure`, that
control the behavior of the emitted instruction sequence when the check
fails:
* `ShouldTrap` requests an error to be generated
* `OnFailure` requests branching to the given label after clearing the
PAC field
An assertion in `emitPtrauthCheckAuthenticatedValue` ensures that when
`ShouldTrap` is true, `OnFailure` must be null. But the opposite holds
as well: when `ShouldTrap` is false, `OnFailure` is always non-null,
as otherwise the entire sequence following `AUT[ID][AB]` instruction
would turn into a very expensive equivalent of XPAC (unless the CPU
implements FEAT_FPAC):
authenticate Xn
inspect PAC field of Xn
if PAC field was not cleared:
clear PAC field
In other words, the value of `ShouldTrap` argument can be computed as
`OnFailure == nullptr` at all existing call sites. In fact, at three
of four call sites, constant `true` and `nullptr` are passed as the
values of these function arguments. `emitPtrauthAuthResign` is the
only caller that potentially makes use of checking-but-not-trapping
mode of `emitPtrauthCheckAuthenticatedValue`, and it passes a non-null
pointer as `OnFailure` when `ShouldTrap` is false.
This commit makes the invariant explicit by omitting the `ShouldTrap`
argument and inferring its value from the `OnFailure` argument instead.
Depends on:
* https://github.com/llvm/llvm-project/pull/168895
Note, the last commit is the one with the actual fix. The others are
drive-by/test changes
We've been seeing dsymutil verification failures like:
```
error: Name Index @ 0x0: Entry @ 0x11949d: mismatched Name of DIE @ 0x9c644c:
index - apply<(lambda at /some/build/dir/lib/LLVMSupport/include/llvm/Support/Error.h:1070:35)>;
debug_info - apply<(lambda at /some/build/dir/lib/LLVMCustom/include/llvm/Support/Error.h:1070:35)>
apply, _ZN11custom_llvm18ErrorHandlerTraitsIRFvRNS_13ErrorInfoBaseEEE5applyIZNS_12consumeErrorENS_5ErrorEEUlRKS1_E_EES7_OT_NSt3__110unique_ptrIS1_NSD_14default_deleteIS1_EEEE.
```
Not how the name of the DIE has a different lambda path than the one
that was used to insert the DIE into debug_names.
The root cause of the issue is that we have a DW_AT_subprogram
definition whose DW_AT_specification DIE got deduplicated. But the
DW_AT_name of the original specification is different than the one it
got uniqued to. That’s technically fine because dsymutil uniques by
linkage name, which uniquely identifies any function with non-internal
linkage.
But we insert the definition DIE into the debug-names table using the
DW_AT_name of the original specification (we call
`getDIENames(InputDIE…)`). But what we really want to do is use the name
of the adjusted `DW_AT_specifcation` (i.e., the `DW_AT_specification` of
the output DIE). That’s not as simple as it sounds because we can’t just
get ahold of the DIE in the output CU. We have to grab the ODR
`DeclContext` of the input DIE’s specification. That is the only link
back to the canonical specification DIE. For that to be of any use, we
have to stash the `DW_AT_name` into `DeclContext` so we can use it in
`getDIENames`.
We have to account for the possibility of multiple levels of
`DW_AT_specification`/`DW_AT_abstract_origin`. So my proposed solution
is to recursively scan the referenced DIE’s, grab the canonical DIE for
those and get the name from the `DeclContext` (if none exists then use
the `DW_AT_name` of the DIE itself).
One remaining question is whether we need to handle the case where a DIE
has a `DW_AT_specification` *and* a `DW_AT_abstract_origin`? That
complicates the way we locate `DW_AT_name`. We'd have to adjust
`getCanonicalDIEName` to handle this. But it's not clear what a
`DW_AT_name` would be for such cases. Worst case at the moment we take
the wrong path up the specifications and don't find any `DW_AT_name`,
and don't end up indexing that DIE. Something to keep an eye out for.
rdar://149239553
Just like the last handful of clauses, this is a pretty simple one,
doing device_resident (Entry op: declare_device_resident, and exit:
delete). This should be the last of the 'local' declare patches.
- The DXIL data scalarizer only needs to change vectors into arrays. It
does not need to change the types of GEPs to match the pointer type.
This PR simplifies the `visitGetElementPtrInst` method to do just that
while also accounting for nested GEPs from ConstantExprs. (Before this
PR, there were still vector types lingering in nested GEPs with
ConstantExprs.)
- The `equivalentArrayTypeFromVector` function was awkwardly placed near
the top of the file and away from the other helper functions. The
function is now moved next to the other helper functions.
- Removed an unnecessary `||` condition from `isVectorOrArrayOfVectors`
Related tests have also been cleaned up, and the test CHECKs have been
modified to account for the new simplified behavior.
This patch adds a case to `CheckMultiVersionAdditionalDecl()` that
detects redeclarations of `target_clones` functions which omit the
attribute, and makes sure they are marked as redeclarations. It also
updates the comment at the call site of
`CheckMultiVersionAdditionalDecl()` to reflect this.
Previously, `target_clones` multiversioned functions that omitted the
attribute from subsequent declarations would cause Clang to hit an
`llvm_unreachable` and crash. In the following example, the second
declaration (the function definition) should inherit the `target_clones`
attribute from the first declaration (the forward declaration):
```
__attribute__((target_clones("arch=atom", "default")))
void foo(void);
void foo(void) { /* ... */ }
```
However, `CheckMultiVersionAdditionalDecl()` was not recognizing the
function definition as a redeclaration of the forward declaration, which
prevented `Sema::MergeFunctionDecl()` from automatically inheriting the
attribute.
A side effect of this fix is that Clang now catches redeclarations of
`target_clones` functions that have conflicting types, which previously
caused Clang to crash by hitting that same `llvm_unreachable`. The
`bad_overload1` case in `clang/test/Sema/attr-target-clones.c` has been
updated to reflect this.
Fixes#165517Fixes#129483
