[LLVM] Add a C API for creating instructions with custom syncscopes. (#104775)

Another upstreaming of C API extensions we have in Julia/LLVM.jl.
Although [we went](https://github.com/maleadt/LLVM.j

[LLVM] Add a C API for creating instructions with custom syncscopes. (#104775)

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

show more ...

Remove the `x86_mmx` IR type. (#98505)

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 wit

Remove the `x86_mmx` IR type. (#98505)

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.

show more ...

[C API] Support new ptrauth constant type (#93909)

This is a new constant type that was added to the C++ API in
0edc97f119f3ac3ff96b11183fe5c001a48a9a8d. This adds the ability to
create instances

[C API] Support new ptrauth constant type (#93909)

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.

show more ...

[C API] Add accessors for new no-wrap flags on GEP instructions (#97970)

Previously, only the inbounds flag was accessible via the C API. This
adds support for any no-wrap related flags (currently

[C API] Add accessors for new no-wrap flags on GEP instructions (#97970)

Previously, only the inbounds flag was accessible via the C API. This
adds support for any no-wrap related flags (currently nuw and nusw).

show more ...

[C API] Add getters for Target Extension Types to C API (#96447)

Accessors for the name, type parameters, and integer parameters are
added. A test is added to echo.ll

This was originally done in

[C API] Add getters for Target Extension Types to C API (#96447)

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

show more ...

[C API] Add getters and build function for CallBr (#91154)

This adds LLVMBuildCallBr to create CallBr instructions, and getters for
the CallBr-specific data. The remainder of its data, e.g.
argume

[C API] Add getters and build function for CallBr (#91154)

This adds LLVMBuildCallBr to create CallBr instructions, and getters for
the CallBr-specific data. The remainder of its data, e.g.
arguments/function, can be accessed using existing getters.

show more ...

[C API] Add accessors for function prefix and prologue data (#82193)

A test is added to echo.ll, and the echo.cpp part of llvm-c-test is
updated to clone a function's prefix and prologue.

[C API] Add getters and setters for fast-math flags on relevant instructions (#75123)

These flags are usable on floating point arithmetic, as well as call,
select, and phi instructions whose result

[C API] Add getters and setters for fast-math flags on relevant instructions (#75123)

These flags are usable on floating point arithmetic, as well as call,
select, and phi instructions whose resulting type is floating point, or
a vector of, or an array of, a valid type. Whether or not the flags are
valid for a given instruction can be checked with the new
LLVMCanValueUseFastMathFlags function.

These are exposed using a new LLVMFastMathFlags type, which is an alias
for unsigned. An anonymous enum defines the bit values for it.

Tests are added in echo.ll for select/phil/call, and the floating point
types in the new float_ops.ll bindings test.

Select and the floating point arithmetic instructions were not
implemented in llvm-c-test/echo.cpp, so they were added as well.

show more ...

[LLVM-C] Support operand bundles (#73914)

Added the following functions for manipulating operand bundles, as well as
building ``call`` and ``invoke`` instructions that use operand bundles:

* L

[LLVM-C] Support operand bundles (#73914)

Added the following functions for manipulating operand bundles, as well as
building ``call`` and ``invoke`` instructions that use operand bundles:

* LLVMBuildCallWithOperandBundles
* LLVMBuildInvokeWithOperandBundles
* LLVMCreateOperandBundle
* LLVMDisposeOperandBundle
* LLVMGetNumOperandBundles
* LLVMGetOperandBundleAtIndex
* LLVMGetNumOperandBundleArgs
* LLVMGetOperandBundleArgAtIndex
* LLVMGetOperandBundleTag

Fixes #71873.

show more ...

[llvm-c] Add support for setting/getting new disjoint flag on or instructions (#74517)

Follows #73952 doing the same thing for the nneg flag on zext (i.e.,
exposing support in the C API).

[C API] Add support for setting/getting new nneg flag on zext instructions (#73592)

This flag was added in #67982, but was not yet accessible via the C API.
This commit adds a getter/setter for thi

[C API] Add support for setting/getting new nneg flag on zext instructions (#73592)

This flag was added in #67982, but was not yet accessible via the C API.
This commit adds a getter/setter for this flag, and a test for it.

show more ...

[C API] Fix LLVMGetOrdering/LLVMIsAtomicSingleThread for fence/memory instrs (#65228)

Fixes https://github.com/llvm/llvm-project/issues/65227

LLVMGetOrdering previously did not support Fence inst

[C API] Fix LLVMGetOrdering/LLVMIsAtomicSingleThread for fence/memory instrs (#65228)

Fixes https://github.com/llvm/llvm-project/issues/65227

LLVMGetOrdering previously did not support Fence instructions, and
calling it on a fence would lead to a bad cast as it
assumed a load/store, or an AtomicRMWInst. This would either read a
garbage memory order, or assertion

LLVMIsAtomicSingleThread did not support either Fence instructions,
loads, or stores, and would similarly lead to a bad cast.
It happened to work out since the relevant types all have their synch
scope ID at the same offset, but it still should be fixed

These cases are now fixed for the C API, and tests for these
instructions are added. The echo test utility now also supports cloning
Fence instructions, which it did not previously

-----

From what I can tell, there's no unified API to pull
`getOrdering`/`getSyncScopeID` from, and instead requires casting to
individual types: if there is a better way of handling this I can switch
to that

show more ...

[C API]: Add getters for inline assembly template string, constraints, and flags

This change adds support for accessing information about inline
assembly calls through the C API, enough to be able t

[C API]: Add getters for inline assembly template string, constraints, and flags

This change adds support for accessing information about inline
assembly calls through the C API, enough to be able to round-trip the
information. This partially addresses https://llvm.org/pr42692 which
points out gaps in the C API

Getters for each of the parameters to LLVMGetInlineAsm/InlineAsm::get
have been added, such that the C API now has enough surface to clone
inline assembly calls

This API currently only returns the raw constraint string via
LLVMGetInlineAsmConstraintString: it may be prudent to also expose the
parsed constraints via InlineAsm::ParseConstraints, but I wasn't sure
how that should look like. This at least exposes the information for
clients

Patch by Benji Smith. Thanks!

Differential Revision: https://reviews.llvm.org/D153185

show more ...

[llvm-c] Add LLVMSetTailCallKind and LLVMGetTailCallKind

Reviewed By: aeubanks

Differential Revision: https://reviews.llvm.org/D153107

[C API] Add getters and setters for NUW, NSW, and Exact

This partially addresses Bug 42692; see discussion there.

Adds C API getters and setters for the NUW, NSW, and Exact flags on various
instruc

[C API] Add getters and setters for NUW, NSW, and Exact

This partially addresses Bug 42692; see discussion there.

Adds C API getters and setters for the NUW, NSW, and Exact flags on various
instructions.

Patch by Craig Disselkoen. Thanks!

Differential Revision: https://reviews.llvm.org/D89252

show more ...

[llvm-c] Add C API methods to match 64bit ArrayType C++ API signatures

Fixes https://github.com/llvm/llvm-project/issues/56496.

As mentioned in the issue, new functions LLVMArrayType2 and
LLVMGetAr

[llvm-c] Add C API methods to match 64bit ArrayType C++ API signatures

Fixes https://github.com/llvm/llvm-project/issues/56496.

As mentioned in the issue, new functions LLVMArrayType2 and
LLVMGetArrayLength2 are created so as to not break the old API.
The old methods are then marked as deprecated and callers are
updated.

Differential Revision: https://reviews.llvm.org/D143700

show more ...

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizati

[IR] Add a target extension type to LLVM.

Target-extension types represent types that need to be preserved through
optimization, but otherwise are not introspectable by target-independent
optimizations. This patch doesn't add any uses of these types by an existing
backend, it only provides basic infrastructure such that these types would work
correctly.

Reviewed By: nikic, barannikov88

Differential Revision: https://reviews.llvm.org/D135202

show more ...

[llvm-c][test] Remove typed pointer support from llvm-c-test echo

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D139364

[llvm-c] Add LLVMGetAggregateElement() function

This adds LLVMGetAggregateElement() as a wrapper for
Constant::getAggregateElement(), which allows fetching a
struct/array/vector element without hand

[llvm-c] Add LLVMGetAggregateElement() function

This adds LLVMGetAggregateElement() as a wrapper for
Constant::getAggregateElement(), which allows fetching a
struct/array/vector element without handling different possible
underlying representations.

As the changed echo test shows, previously you for example had to
treat ConstantArray (use LLVMGetOperand) and ConstantDataArray
(use LLVMGetElementAsConstant) separately, not to mention all the
other possible representations (like PoisonValue).

I've deprecated LLVMGetElementAsConstant() in favor of the new
function, which is strictly more powerful (but I could be convinced
to drop the deprecation).

This is partly motivated by https://reviews.llvm.org/D125795,
which drops LLVMConstExtractValue() because the underlying constant
expression no longer exists. This function could previously be used
as a poor man's getAggregateElement().

Differential Revision: https://reviews.llvm.org/D128417

show more ...

[llvm-c-test] Default to opaque pointers

[llvm-c-test] Always set opaque pointers mode

Avoid a behavior change when opaque pointers are enabled by default.

[llvm-c] Add functions for enabling and creating opaque pointers

This is based on https://reviews.llvm.org/D125168 which adds a
wrapper to allow use of opaque pointers from the C API.

I added an op

[llvm-c] Add functions for enabling and creating opaque pointers

This is based on https://reviews.llvm.org/D125168 which adds a
wrapper to allow use of opaque pointers from the C API.

I added an opaque pointer mode test to echo.ll, and to fix assertions
that forbid the use of mixed typed and opaque pointers that were
triggering in it I had to also add wrappers for setOpaquePointers()
and isOpaquePointer().

I also changed echo.ll to remove a bitcast i32* %x to i8*, because
passing it through llvm-as and llvm-dis was generating a
%0 = bitcast ptr %x to ptr, but when building that same bitcast in
echo.cpp it was getting elided by IRBuilderBase::CreateCast
(https://github.com/llvm/llvm-project/blob/08ac66124874d70dab63c731da0244f9e29ef168/llvm/include/llvm/IR/IRBuilder.h#L1998-L1999).

Differential Revision: https://reviews.llvm.org/D125183

show more ...

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avo

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avoiding hidden ehader dependencies, something
the LLVM codebase doesn't do that well :-/

I've tried to summarize the biggest change below:

- llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h
- llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h
- llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h
- llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h
- llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h
- llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h
- llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h

And the usual count of preprocessed lines:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 6400831
after: 6189948

200k lines less to process is no that bad ;-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

Differential Revision: https://reviews.llvm.org/D118652

show more ...

[llvm-c] Accept GEP operators in some APIs

As requested in D115787, I've added a test for LLVMConstGEP2 and
LLVMConstInBoundsGEP2. However, to make this work in the echo test,
I also had to change a

[llvm-c] Accept GEP operators in some APIs

As requested in D115787, I've added a test for LLVMConstGEP2 and
LLVMConstInBoundsGEP2. However, to make this work in the echo test,
I also had to change a couple of APIs to work on GEP operators,
rather than only GEP instructions.

Differential Revision: https://reviews.llvm.org/D115858

show more ...

[llvm-c] Avoid deprecated APIs in tests

Avoid the use of deprecated (opaque pointer incompatible) APIs
in C API tests, in preparation for header deprecation. Add a
LLVMGetGEPSourceElementType() to c

[llvm-c] Avoid deprecated APIs in tests

Avoid the use of deprecated (opaque pointer incompatible) APIs
in C API tests, in preparation for header deprecation. Add a
LLVMGetGEPSourceElementType() to cover a bit of functionality
that is necessary for the echo test.

This change is split out from https://reviews.llvm.org/D114936.

show more ...