When emitting references to functions as part of `ValueAsMetadata`,
we currently emit the incorrect (typed) pointer, resulting in
crashes during deserialization. Avoid this by correctly mapping the
type during serialization.
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.
The icmp and fcmp constant expressions were removed in deab451e7a7f
"[IR] Remove support for icmp and fcmp constant expressions (#93038)".
Update the DXILBitcodeWriter to stop referencing them.
We were running out of abbrevs and crashing if there were more than 20
something strings in metadata, which turned out to be a bug where we
created an abbrev every time we emitted a string rather than just one
for the string table.
Differential Revision: https://reviews.llvm.org/D158440
I just tried to build all experimental targets and noticed that DirectX did
not build with -DBUILD_SHARED_LIBS=ON.
Differential Revision: https://reviews.llvm.org/D138431
1. Save typed pointer type for GlobalVariable/Function instead of the ObjectType.
This will allow use GlobalVariable/Function as value.
2. Save target type for global ctors for Constant.
3. In DXILBitcodeWriter::getTypeID, check PointerMap first for Constant case.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D133283
1. Save typed pointer type for GlobalVariable/Function instead of the ObjectType.
This will allow use GlobalVariable/Function as value.
2. Save target type for global ctors for Constant.
3. In DXILBitcodeWriter::getTypeID, check PointerMap first for Constant case.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D133283
This assert always fails. It is unclear to me what it was attempting to
test, but removing it gets our tests passing, so it clearly isn't
checking the right thing.
Use onstantDataSequential::getElementType to allow vector type.
Use getShuffleMaskForBitcode to get ShuffleMask.
Use old format for alloca Align.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D132102
This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR--the type is intended
to remain an auxiliary type, not a real LLVM type. So no support is provided for
LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make
Type->dump() work properly).
Reviewed By: beanz, nikic, aeubanks
Differential Revision: https://reviews.llvm.org/D130592
llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.
Reviewed By: nhaehnle
Differential Revision: https://reviews.llvm.org/D130406
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
When writeValueAsMetadata for GlobalVariable and Function, write TypedPointerType for ValueType and FunctionType.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D127705
Using the pointer type analysis we can re-constitute typed pointers and
populate the correct types in the bitcasts throughout the IR.
This doesn't yet handle all cases, but this should be illustrative as
to the dirction and feasability of
the solution.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D122270
DXIL doesn't support attributes added after LLVM 3.7. The DXILPrepare
pass removes those attributes so they should never be present by the
time we reach the DXIL bitcode writer.
In the event that we somehow try to write a newer attribute in the DXIL
writer, we should fail hard (crash), because the output would be
invalid. This case should only be possible if the DXIL writer were
called without DXILPrepare being run first, which shouldn't be possible.
This patch also adds a default case to the switch statement over the
attribute list which covers all the removed cases and any new attribute
kinds that may be added in the future. The default case is handled like
other unsupported cases by a call to llvm_unreachable.
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
This change is a big blob of code that isn't easy to break up. It
either comes in all together as a blob, works and has tests, or it
doesn't do anything.
Logically you can think of this patch as three things:
(1) Adding virtual interfaces so the bitcode writer can be overridden
(2) Adding a new bitcode writer implementation for DXIL
(3) Adding some (optional) crazy CMake goop to build the
DirectXShaderCompiler's llvm-dis as dxil-dis for testing
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D122082
