| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates symbols that were added to
LLVM in the last two weeks and were missed by previous code-mods. The
annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Overview
These changes were generated automatically using the [Interface
Definition Scanner (IDS)](https://github.com/compnerd/ids) tool,
followed formatting with `git clang-format`.
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
|
|
`g_cpu_features` can be updated multiple times by `get_cpu_features()`,
which reports a thread sanitizer error when used with multiple lld
threads.
This PR updates BLAKE3 to v1.8.2.
|
|
replace arrays (#135607)
This change adds some support to the C DebugInfo capability to create set types,
subrange types, dynamic array types and the ability to replace arrays.
|
|
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm-c` interface with a
new `LLVM_C_ABI` annotation, which behaves like the `LLVM_ABI`. This
annotation currently has no meaningful impact on the LLVM build;
however, it is a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Overview
1. Add a new `llvm-c/Visibility.h` header file that defines a new
`LLVM_C_ABI` macro. The macro resolves to the proper DLL export/import
annotation on Windows and a "default" visibility annotation elsewhere.
2. Add a new `LLVM_ENABLE_LLVM_C_EXPORT_ANNOTATIONS` `#cmakedefine` that
is used to gate the definition of `LLVM_C_ABI`.
3. Remove the existing `LLVM_C_ABI` definition from
`llvm/Support/Compiler.h`. Update the small number of `LLVM_C_ABI`
references to get it from the new `llvm-c/Visibility.h` header.
4. Code-mod annotate the public `llvm-c` interface using the [Interface
Definition Scanner (IDS)](https://github.com/compnerd/ids) tool.
5. Format the changes with `clang-format`.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
|
|
This removes ThreadSafeContext::Lock, ThreadSafeContext::getLock, and
ThreadSafeContext::getContext, and replaces them with a
ThreadSafeContext::withContextDo method (and const override).
The new method can be used to access an existing
ThreadSafeContext-wrapped LLVMContext in a safe way:
ThreadSafeContext TSCtx = ... ;
TSCtx.withContextDo([](LLVMContext *Ctx) {
// this closure has exclusive access to Ctx.
});
The new API enforces correct locking, whereas the old APIs relied on
manual locking (which almost no in-tree code preformed, relying instead
on incidental exclusive access to the ThreadSafeContext).
|
|
Add new APIs to legacy LTO C API to surface undefined symbols that
parsed from assembly. This information is needed by thin LTO to figure
out the symbols not to dead strip, while such information is
automatically forwarded in full LTO already. Linker needs to fetch the
information and adds the undefs from assembly to MustPreserveSymbols
list just like treating undefs from a non-LTO object file.
Resolves: https://github.com/llvm/llvm-project/issues/29340
|
|
The C API does not provide a way to replace the subroutine type after
creating a subprogram. This functionality is useful for creating a
subroutine type composed of types which have the subprogram as scope
|
|
This was added to the C++ API in
https://github.com/llvm/llvm-project/pull/111419 so this change adds
accessors in the C API, along with a couple tests.
|
|
(#92467)
Clarify that these functions are no-ops when linking to LLVM as a shared object.
|
|
In 38d16f509a3faff3c545da5bfd5a8bcbd234ff24, the `TargetTriple` argument
was removed from the `LLVMOrcCreateStaticLibrarySearchGeneratorForPath`
without updating the C API headers. This resulted in the function being
exported without C linkage, making it impossible to use from C.
Co-authored-by: Lang Hames <lhames@gmail.com>
|
|
instructions (#137701)
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.
These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.
Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.
|
|
instructions" (#137657)
Reverts llvm/llvm-project#136759 due to bad interaction with c792b25e4
|
|
(#136759)
This patch adds support for LLVM IR atomicrmw `fmaximum` and `fminimum`
instructions.
These mirror the `llvm.maximum.*` and `llvm.minimum.*` instructions, but
are atomic and use IEEE754 2019 handling for NaNs, which is different to
`fmax` and `fmin`. See:
https://llvm.org/docs/LangRef.html#llvm-minimum-intrinsic
for more details.
Future changes will allow this LLVM IR to be lowered to specialised
assembler instructions on suitable targets, such as AArch64.
|
|
Since `LLVMDIBuilderCreateEnumerator` only supports up to 64 bits, this
PR adds a new `LLVMDIBuilderCreateEnumeratorOfArbitraryPrecision`
function that takes an arbitrary number of words, based on
`LLVMConstIntOfArbitraryPrecision`. This allows even larger enumeration
types to represent their values exactly. (It seems LLVM should already
support i128 enums since 13.0.0.)
|
|
Resolves #129439.
The addition to `echo.ll` is for testing `ConstantArray`, because every
other array in that file is in fact a `ConstantDataArray` and now takes
the new code path in `echo.cpp`.
|
|
Fixes breakage of OCaml API introduced by commit 6894734.
|
|
This adds DWARF generation for fixed-point types. This feature is needed
by Ada.
Note that a pre-existing GNU extension is used in one case. This has
been emitted by GCC for years, and is needed because standard DWARF is
otherwise incapable of representing these types.
|
|
- Move LLVMDISubrangeTypeMetadataKind to end of LLVMMetadataKind enum.
Inserting a new enum constant in the middle of the enum breaks the ABI for
that enum. Commit e298fc2 introduced this issue, which was revealed because
the OCaml binding tests failed.
- Bring OCaml bindings up to date with LLVMMetadataKind enum.
|
|
(#132102)
|
|
An Ada program can have types that are subranges of other types. This
patch adds a new DIType node, DISubrangeType, to represent this concept.
I considered extending the existing DISubrange to do this, but as
DISubrange does not derive from DIType, that approach seemed more
disruptive.
A DISubrangeType can be used both as an ordinary type, but also as the
type of an array index. This is also important for Ada.
Ada subrange types can also be stored using a bias. Representing this in
the DWARF required the use of an extension. GCC has been emitting this
extension for years, so I've reused it here.
|
|
Remove support for the mul constant expression, which has previously
already been marked as undesirable. This removes the APIs to create mul
expressions and updates tests to stop using mul expressions.
Part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179
|
|
enum LLVMLandingPadClauseTy has never been used and exists by mistake.
[This](https://github.com/llvm-mirror/llvm/commit/772fe17a6d07304ae2e6b3052bbb24ebb751f0f3#diff-9e2da57026497163c9f7396a48567626a0b94828a5757436ef20a4e67522525d) commit added a LLVMAddClause function that took it as a parameter.
[Here](https://github.com/llvm-mirror/llvm/commit/10c6d12a9fd4dab411091f64db4db69670b88850#diff-6e588c82c378e251a7d265b08973d4a7312a592756f88023cd317f109083de10) the enum was removed.
And [here](https://github.com/llvm-mirror/llvm/commit/e6e8826870bee3facb04f950f0bd725f8a88623d#diff-9e2da57026497163c9f7396a48567626a0b94828a5757436ef20a4e67522525d) it is added again by mistake, although the LLVMAddClause function no longer accepts it
|
|
declarations with explicit `this`" (#123455)
This reverts commit c3a935e3f967f8f22f5db240d145459ee621c1e0.
The only change to the reverted commit is that this also updates
the OCaml bindings according to the C debug-info API changes.
The build failure originally introduced was:
```
FAILED: bindings/ocaml/debuginfo/debuginfo_ocaml.o /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.o
cd /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo && /usr/bin/ocamlfind ocamlc -c /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c -ccopt "-I/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/bindings/ocaml/debuginfo/../llvm -D_GNU_SOURCE -D_DEBUG -D_GLIBCXX_ASSERTIONS -DEXPENSIVE_CHECKS -D_GLIBCXX_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/1/llvm-clang-x86_64-expensive-checks-debian/build/include -I/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/include -DNDEBUG "
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c: In function ‘llvm_dibuild_create_object_pointer_type’:
/b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c:620:30: error: too few arguments to function ‘LLVMDIBuilderCreateObjectPointerType’
620 | LLVMMetadataRef Metadata = LLVMDIBuilderCreateObjectPointerType(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /b/1/llvm-clang-x86_64-expensive-checks-debian/build/bindings/ocaml/debuginfo/debuginfo_ocaml.c:23:
/b/1/llvm-clang-x86_64-expensive-checks-debian/llvm-project/llvm/include/llvm-c/DebugInfo.h:880:17: note: declared here
880 | LLVMMetadataRef LLVMDIBuilderCreateObjectPointerType(LLVMDIBuilderRef Builder,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
|
|
declarations with explicit `this`" (#123455)
Reverts llvm/llvm-project#122928
|
|
explicit `this` (#122928)
In https://github.com/llvm/llvm-project/pull/122897 we started attaching
`DW_AT_object_pointer` to function definitions. This patch does the same
but for function declarations (which we do for implicit object pointers
already).
Fixes https://github.com/llvm/llvm-project/issues/120974
|
|
Unfortunately there's no upstream frontend for Metal but since the id's
are now assigned by the DWARF standard I think it makes sense to have
the enums upstream to enable tools like llvm-dwarfdump. This patch
therefore uses an AArch64 test with artificially modified debug info to
verify that the Metal language id can be used.
https://dwarfstd.org/issues/241111.1.html
|
|
Change the return type of `LLVMIntrinsicCopyOverloadedName` and
`LLVMIntrinsicCopyOverloadedName2` to `char *` instead of `const char *`
since the returned memory is owned by the caller and we expect that the
returned pointer is passed to free to deallocate it (without casting it
back to non-const pointer).
|
|
Addresses #112799
|
|
|
|
Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).
|
|
Move static functions `Function::lookupIntrinsicID` and
`Function::isTargetIntrinsic` to Intrinsic namespace.
|
|
Since the migration to opaque pointers, CreateGlobalStringPtr()
is the same as CreateGlobalString(). Normalize to the latter.
|
|
These were added in the C++ API in
https://github.com/llvm/llvm-project/pull/105568 but were not exposed
via the C API previously
|
|
Since the migration from `@llvm.dbg.value` intrinsic to `#dbg_value`
records, there is no way to retrieve the debug records for an
`Instruction` in LLVM-C API.
Previously, with debug info intrinsics, retrieving debug info for an
`Instruction` could be done with `LLVMGetNextInstructions`, because the
intrinsic call was also an instruction.
However, to be able to retrieve debug info with the current LLVM, where
debug records are used, the `getDbgRecordRange()` iterator needs to be
exposed.
Add new functions for DbgRecord sequence traversal:
LLVMGetFirstDbgRecord
LLVMGetLastDbgRecord
LLVMGetNextDbgRecord
LLVMGetPreviousDbgRecord
See llvm/docs/RemoveDIsDebugInfo.md and release notes.
|
|
Another upstreaming of C API extensions we have in Julia/LLVM.jl.
Although [we went](https://github.com/maleadt/LLVM.jl/pull/431) with a
string-based API there, here I'm proposing something that's similar to
existing metadata/attribute APIs:
- explicit functions to map syncscope names to IDs, and back
- `LLVM*SyncScope` versions of builder APIs that already take a
`SingleThread` argument: atomic rmw, atomic xchg, fence
- `LLVMGetAtomicSyncScopeID` and `LLVMSetAtomicSyncScopeID` for other
atomic instructions
- testing through `llvm-c-test`'s `--echo` functionality
|
|
Small PR to add additional getters for LLVMContextRef in the C API.
|
|
By adding a new entrypoint, `LLVMRunPassesOnFunction`, as suggested in
https://discourse.llvm.org/t/newpm-c-api-questions/80598.
Also removes erroneous `LLVMConsumeError`s from the pass builder unit
tests as the string conversion already consumes the error, causing an
abort when the test would fail.
|
|
LLVMGetNamedGlobal (#103396)
Add `LLVMGetNamedFunctionWithLength` and `LLVMGetNamedGlobalWithLength`
As far as i know, it isn't currently possible to use
`LLVMGetNamedFunction` and `LLVMGetNamedGlobal` with non-null-terminated
strings.
These new functions are more convenient for C programs that use
non-null-terminated strings or for languages like Rust that primarily
use non-null-terminated strings.
|
|
This PR adds a field to the pass builder options struct, `AAPipeline`,
exposed through a C API `LLVMPassBuilderOptionsSetAAPipeline`, that is
used to set an alias analysis pipeline to be used in stead of the
default one.
x-ref https://discourse.llvm.org/t/newpm-c-api-questions/80598
|
|
It's barely testable - the test does exercise the code, but wouldn't
fail on an empty implementation. It would cause a memory leak though
(because the error handle wouldn't be unwrapped/reowned) which could be
detected by asan and other leak detectors.
|
|
`LLVMSizeOfTypeInBits`:
- `Computes the size of a type in bytes for a target` -> `Computes the
size of a type in bits for a target`
|
|
It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.
This _incompatibly_ changes the ABI of any LLVM IR function with
`x86_mmx` arguments or returns: instead of passing in mmx registers,
they will now be passed via integer registers. However, the real-world
incompatibility caused by this is expected to be minimal, because Clang
never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>`
or `double`, depending on ABI.
This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type.
That type simply no longer corresponds to an IR type, and is used only
by MMX intrinsics and inline-asm operands.
Because SelectionDAGBuilder only knows how to generate the
operands/results of intrinsics based on the IR type, it thus now
generates the intrinsics with the type MVT::v1i64, instead of
MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus
have the X86 backend fix them up in DAGCombine. (This may be a
short-lived hack, if all the MMX intrinsics can be removed in upcoming
changes.)
Works towards issue #98272.
|
|
This is a new constant type that was added to the C++ API in
0edc97f119f3ac3ff96b11183fe5c001a48a9a8d. This adds the ability to
create instances of this constant and get its values to the C API.
|
|
Previously, only the inbounds flag was accessible via the C API. This
adds support for any no-wrap related flags (currently nuw and nusw).
|
|
Accessors for the name, type parameters, and integer parameters are
added. A test is added to echo.ll
This was originally done in
https://github.com/llvm/llvm-project/pull/71291 but that has been stale
for several months. This re-applies the changes, but with some tweaks.
e.g. removing the bulk getters in favour of a simple get-by-index
approach for the type/integer parameters. The latter is more in line
with the rest of the API
|
|
Remove support for shl constant expressions, as part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179
|
|
The DIBuilder C API was changed to deal with DbgRecord functions:
https://github.com/llvm/llvm-project/pull/84915
https://github.com/llvm/llvm-project/pull/85657
https://github.com/llvm/llvm-project/pull/92417#issuecomment-2120078326
As discussed by @nikic and @OCHyams:
https://github.com/llvm/llvm-project/pull/92417#issuecomment-2144505440
> For the intrinsic-inserting functions, do you think we should:
>
> a) mark as deprecated but otherwise leave them alone for now.
> b) mark as deprecated and change their behaviour so that they
> do nothing and return nullptr.
> c) outright delete them (it sounds like you're voting this one,
> but just wanted to double check).
This patch implements option (c).
|
|
|
|
|
|
funcs (#92417)
Add `LLVMPositionBuilderBeforeDbgRecords` and
`LLVMPositionBuilderBeforeInstrAndDbgRecords` to `llvm/include/llvm-c/Core.h`
which behave the same as `LLVMPositionBuilder` and `LVMPositionBuilderBefore`
except that the position is set before debug records attached to the target
instruction (the existing functions set the insertion point to after any
attached debug records).
More info on debug records and the migration towards using them can be found
here: https://llvm.org/docs/RemoveDIsDebugInfo.html
The distinction is important in some situations. An important example is when
inserting a phi before another instruction which has debug records attached to
it (these come "before" the instruction). Inserting before the instruction but
after the debug records would result in having debug records before a phi, which
is illegal. That results in an assertion failure:
`llvm/lib/IR/Instruction.cpp:166: Assertion '!isa<PHINode>(this) && "Inserting
PHI after debug-records!"' failed.`
In llvm (C++) we've added bit to instruction iterators that carries around the
extra information. Adding dedicated functions seemed like the least invasive and
least suprising way to update the C API.
Update llvm/tools/llvm-c-test/debuginfo.c to test this functionality.
Update the OCaml bindings, the migration docs and release notes.
|
