| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This patch fixes:
llvm/tools/llvm-c-test/debuginfo.c:447:27: error: unused variable
'ME' [-Werror,-Wunused-variable]
|
|
This change allows globals to have multiple metadata attached. The
GlobalSetMetadata function only allows only one and is clobbered if
more metadata is attempted to be added. The addDebugInfo
function calls addMetadata. This is needed because some languages have
global structs containing lots of compiler-generated globals.
|
|
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.
|
|
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.
|
|
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`.
|
|
Addresses #112799
|
|
(#105702)
The former name was introduced during the split between debug info
intrinsic and `DbgRecord`. Before the split, it was named
`--test-dibuilder`.
However, the full migration to `DbgRecord` happened already and we have
just one test suite related to building debug info using LLVM-C API.
Therefore, it makes sense to rename it back to `--test-dibuilder`.
|
|
This patch fixes:
llvm/tools/llvm-c-test/debuginfo.c:254:20: error: unused variable
'AddDbgRecordLast' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/debuginfo.c:257:20: error: unused variable
'AddDbgRecordOverTheRange' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/debuginfo.c:264:20: error: unused variable
'AddDbgRecordUnderTheRange' [-Werror,-Wunused-variable]
|
|
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
|
|
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
|
|
/llvm-project/llvm/tools/llvm-c-test/llvm-c-test.h:39:24:
error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int llvm_test_dibuilder();
^
void
1 error generated.
|
|
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.
|
|
`llvm_test_dibuilder(/*NewDebugInfoMode=*/true)` isn't currently executed in
`return llvm_test_dibuilder(false) && llvm_test_dibuilder(true);`
because `llvm_test_dibuilder` returns 0 for success.
Split the llvm-c-test flag `--test-dibuilder` into two, one for the old and
one for the new debug info format. Add another lit test for the new format.
Now that the test actually runs, it crashes using the new format with
`llvm/lib/IR/LLVMContextImpl.cpp:53:llvm::LLVMContextImpl::~LLVMContextImpl(): Assertion 'TrailingDbgRecords.empty() && "DbgRecords in blocks not cleaned"' failed. Aborted`.
Insert terminators into the blocks so that we don't leave the debug records
trailing, unattached to any instructions, which fixes that.
|
|
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.
|
|
Follow on from #84915 which adds the DbgRecord function variants. The C API
changes were reviewed in #85657.
# C API
Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.
LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd
Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".
Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.
Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.
# OCaml bindings
Add set_is_new_dbg_info_format and is_new_dbg_info_format to the OCaml bindings.
These can be used to set and query the current debug info mode. These will
eventually be removed, but are useful while we're transitioning between old and
new debug info formats.
Add string_of_lldbgrecord, like string_of_llvalue but prints DbgRecords.
In test dbginfo.ml, unconditionally set the module debug info to the new mode
and update CHECK lines to check for DbgRecords. Without this change the test
crashes because it attempts to insert DbgRecords (new default behaviour of
llvm_dibuild_insert_declare_...) into a module that is in the old debug info
mode.
|
|
(#85657)"
This reverts commit 2091c74796b1dac68e622284c63a870b88b7554f.
Builtbot failure: https://lab.llvm.org/buildbot/#/builders/16/builds/63080
|
|
Follow on from #84915 which adds the DbgRecord function variants.
Update the LLVMDIBuilderInsert... functions to insert DbgRecords instead
of debug intrinsics.
LLVMDIBuilderInsertDeclareBefore
LLVMDIBuilderInsertDeclareAtEnd
LLVMDIBuilderInsertDbgValueBefore
LLVMDIBuilderInsertDbgValueAtEnd
Calling these functions will now cause an assertion if the module is in the
wrong debug info format. They should only be used when the module is in "new
debug format".
Use LLVMIsNewDbgInfoFormat to query and LLVMSetIsNewDbgInfoFormat to change the
debug info format of a module.
Please see https://llvm.org/docs/RemoveDIsDebugInfo.html#c-api-change
(RemoveDIsDebugInfo.md) for more info.
|
|
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.
|
|
Follow on from #84739, which updates the DIBuilder class.
All the functions that have been added are temporary and will be
deprecated in the future. The intention is that they'll help downstream
projects adapt during the transition period.
```
New functions (all to be deprecated)
------------------------------------
LLVMIsNewDbgInfoFormat # Returns true if the module is in the new non-instruction mode.
LLVMSetIsNewDbgInfoFormat # Convert to the requested debug info format.
LLVMDIBuilderInsertDeclareIntrinsicBefore # Insert a debug intrinsic (old debug info format).
LLVMDIBuilderInsertDeclareIntrinsicAtEnd # Same as above.
LLVMDIBuilderInsertDbgValueIntrinsicBefore # Same as above.
LLVMDIBuilderInsertDbgValueIntrinsicAtEnd # Same as above.
LLVMDIBuilderInsertDeclareRecordBefore # Insert a debug record (new debug info format).
LLVMDIBuilderInsertDeclareRecordAtEnd # Same as above.
LLVMDIBuilderInsertDbgValueRecordBefore # Same as above.
LLVMDIBuilderInsertDbgValueRecordAtEnd # Same as above.
```
The existing `LLVMDIBuilderInsert...` functions call through to the
intrinsic versions (old debug info format) currently.
In the next patch, I'll swap them to call the debug records versions
(new debug info format). Downstream users of this API can query and
change the current format using the first two functions above, or can
instead opt to temporarily use intrinsics or records explicitly.
|
|
(#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.
|
|
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.
|
|
instructions (#74517)
Follows #73952 doing the same thing for the nneg flag on zext (i.e.,
exposing support in the C API).
|
|
(#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.
|
|
(#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
|
|
This code path doesn't exist anymore.
|
|
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
|
|
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D153107
|
|
This function otherwise crashes. This behavior has been incorrect since
its introduction in 260b581498bed0b847e7e086852e0082d266711d (D46627).
Reviewed By: scott.linder
Differential Revision: https://reviews.llvm.org/D154630
|
|
Address clang-tidy warnings, correct usage text.
Differential Revision: https://reviews.llvm.org/D154661
|
|
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
|
|
Remove C APIs for interacting with PassRegistry and pass
initialization. These are legacy PM concepts, and are no longer
relevant for the new pass manager.
Calls to these initialization functions can simply be dropped.
Differential Revision: https://reviews.llvm.org/D145043
|
|
The legacy PM is only supported for codegen, and PassManagerBuilder
is exclusively about the middle-end optimization pipeline. Drop it.
Differential Revision: https://reviews.llvm.org/D145387
|
|
Legacy passes are only supported for codegen, and I don't believe
it's possible to write backends using the C API, so we should drop
all of those. Reduces the number of places that need to be modified
when removing legacy passes.
Differential Revision: https://reviews.llvm.org/D144970
|
|
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
|
|
|
|
This patch fixes:
llvm/tools/llvm-c-test/debuginfo.c:211:12: error: unused variable
'tag0' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/debuginfo.c:222:12: error: unused variable
'tag1' [-Werror,-Wunused-variable]
|
|
Differential Revision: https://reviews.llvm.org/D138415
|
|
This patch fixes:
llvm/tools/llvm-c-test/metadata.c:49:16: error: unused variable
'tmp' [-Werror,-Wunused-variable]
llvm-project/llvm/tools/llvm-c-test/metadata.c:70:16: error: unused
variable 'md' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/metadata.c:74:16: error: unused variable
'md2' [-Werror,-Wunused-variable]
|
|
I'm working on a tool that visits debug info and massages it using the
llvm-c API. I noticed that LLVMGetOperand special cases MDNodes so I
can get their operands, but I can't replace them. This patch adds
LLVMReplaceMDNodeOperandWith which boils down to
MDNode::replaceOperandWith.
The name was chosen for consistency with LLVMGetMDNodeOperands and
LLVMGetMDNodeNumOperands.
Differential Revision: https://reviews.llvm.org/D136637
|
|
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
|
|
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D139364
|
|
As part of legacy PM optimization pipeline removal.
This shouldn't be used in codegen pipelines so it should be ok to remove.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D137116
|
