[IR] Remove support for float binop constant expressions

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constan

[IR] Remove support for float binop constant expressions

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constant expressions
fadd, fsub, fmul, fdiv and frem.

As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub,
LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed.
The LLVMBuild APIs should be used instead.

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

show more ...

ManagedStatic: remove many straightforward uses in llvm

(Reapply after revert in e9ce1a588030d8d4004f5d7e443afe46245e9a92 due to
Fuchsia test failures. Removed changes in lib/ExecutionEngine/ other

ManagedStatic: remove many straightforward uses in llvm

(Reapply after revert in e9ce1a588030d8d4004f5d7e443afe46245e9a92 due to
Fuchsia test failures. Removed changes in lib/ExecutionEngine/ other
than error categories, to be checked in more detail and reapplied
separately.)

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

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

show more ...

Revert "ManagedStatic: remove many straightforward uses in llvm"

This reverts commit e6f1f062457c928c18a88c612f39d9e168f65a85.

Reverting due to a failure on the fuchsia-x86_64-linux buildbot.

ManagedStatic: remove many straightforward uses in llvm

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,

ManagedStatic: remove many straightforward uses in llvm

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

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

show more ...

llvm-c: Add LLVMDeleteInstruction to fix a test issue

Not deleting the loose instruction with metadata associated to it causes
an assertion when the LLVMContext is destroyed. This was previously
hid

llvm-c: Add LLVMDeleteInstruction to fix a test issue

Not deleting the loose instruction with metadata associated to it causes
an assertion when the LLVMContext is destroyed. This was previously
hidden by the fact that llvm-c-test does not call LLVMShutdown. The
planned removal of ManagedStatic exposed this issue.

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

show more ...

[LLVM] Add the support for fmax and fmin in atomicrmw instruction

This patch adds the support for `fmax` and `fmin` operations in `atomicrmw`
instruction. For now (at least in this patch), the instr

[LLVM] Add the support for fmax and fmin in atomicrmw instruction

This patch adds the support for `fmax` and `fmin` operations in `atomicrmw`
instruction. For now (at least in this patch), the instruction will be expanded
to CAS loop. There are already a couple of targets supporting the feature. I'll
create another patch(es) to enable them accordingly.

Reviewed By: arsenm

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

show more ...

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDi

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDiv(), getExactSDiv(), getURem()
and getSRem() on ConstantExpr are removed, and ConstantExpr::get()
now only accepts binary operators for which
ConstantExpr::isSupportedBinOp() returns true. Uses of these methods
may be replaced either by corresponding IRBuilder methods, or
ConstantFoldBinaryOpOperands (if a constant result is required).

On the C API side, LLVMConstUDiv, LLVMConstExactUDiv, LLVMConstSDiv,
LLVMConstExactSDiv, LLVMConstURem and LLVMConstSRem are removed and
corresponding LLVMBuild methods should be used.

Importantly, this also means that constant expressions can no longer
trap! This patch still keeps the canTrap() method to minimize diff --
I plan to drop it in a separate NFC patch.

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

show more ...

[IR] Remove support for insertvalue constant expression

This removes the insertvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
This is

[IR] Remove support for insertvalue constant expression

This removes the insertvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
This is very similar to the extractvalue removal from D125795.
insertvalue is also not supported in bitcode, so no auto-ugprade
is necessary.

ConstantExpr::getInsertValue() can be replaced with
IRBuilder::CreateInsertValue() or ConstantFoldInsertValueInstruction(),
depending on whether a constant result is required (with the latter
being fallible).

The ConstantExpr::hasIndices() and ConstantExpr::getIndices()
methods also go away here, because there are no longer any constant
expressions with indices.

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

show more ...

[IR] Remove support for extractvalue constant expression

This removes the extractvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
extrac

[IR] Remove support for extractvalue constant expression

This removes the extractvalue constant expression, as part of
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179.
extractvalue is already not supported in bitcode, so we do not need
to worry about bitcode auto-upgrade.

Uses of ConstantExpr::getExtractValue() should be replaced with
IRBuilder::CreateExtractValue() (if the fact that the result is
constant is not important) or ConstantFoldExtractValueInstruction()
(if it is). Though for this particular case, it is also possible
and usually preferable to use getAggregateElement() instead.

The C API function LLVMConstExtractValue() is removed, as the
underlying constant expression no longer exists. Instead,
LLVMBuildExtractValue() should be used (which will constant fold
or create an instruction). Depending on the use-case,
LLVMGetAggregateElement() may also be used instead.

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

show more ...

[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 ...

[NFC][Alignment] Use proper type in LLVMGetAlignment

[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 ...

[CAPI] Expose CastInst::getCastOpcode in C API

Reviewed By: deadalnix

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

Add PointerType analysis for DirectX backend

As implemented this patch assumes that Typed pointer support remains in
the llvm::PointerType class, however this could be modified to use a
different su

Add PointerType analysis for DirectX backend

As implemented this patch assumes that Typed pointer support remains in
the llvm::PointerType class, however this could be modified to use a
different subclass of llvm::Type that could be disallowed from use in
other contexts.

This does not rely on inserting typed pointers into the Module, it just
uses the llvm::PointerType class to track and unique types.

Fixes #54918

Reviewed By: kuhar

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

show more ...

[llvm-c] Document that LLVMGetElementType on pointers is deprecated (NFC)

We can't actually deprecate the function, because it is also used
for arrays and vectors, so we can only document this.

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] Deprecate LLVMBuildPtrDiff()

In favor of LLVMBuildPtrDiff2(), which accepts an explicit element
type and is compatible with opaque pointers.

[IRBuilder] Require explicit element type in CreatePtrDiff()

For opaque pointer compatibility, we cannot derive the element
type from the pointer type.

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...

[OpaquePtrs] Add getNonOpaquePointerElementType() method (NFC)

This method is intended for use in places that cannot be reached
with opaque pointers, or part of deprecated methods. This makes
it eas

[OpaquePtrs] Add getNonOpaquePointerElementType() method (NFC)

This method is intended for use in places that cannot be reached
with opaque pointers, or part of deprecated methods. This makes
it easier to see that some uses of getPointerElementType() don't
need further action.

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

show more ...

[LLVM-C] Use NameLen in LLVMGetNamedGlobalAlias

I tried to look over the file and didn't see any other non-use of *Len variables.

Reviewed By: deadalnix

Differential Revision: https://reviews.llvm

[LLVM-C] Use NameLen in LLVMGetNamedGlobalAlias

I tried to look over the file and didn't see any other non-use of *Len variables.

Reviewed By: deadalnix

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

show more ...

[llvm] Use nullptr instead of 0 (NFC)

Identified with modernize-use-nullptr.

[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] Make LLVMConstGEP/LLVMConstInBoundsGEP opaque pointer compatible

Weirdly, the opaque pointer compatible variants LLVMConstGEP2 and
LLVMConstInBoundsGEP2 were already declared in the header,

[llvm-c] Make LLVMConstGEP/LLVMConstInBoundsGEP opaque pointer compatible

Weirdly, the opaque pointer compatible variants LLVMConstGEP2 and
LLVMConstInBoundsGEP2 were already declared in the header, but not
actually implemented. This adds the missing implementations and
deprecates the incompatible functions.

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

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 ...