The byte type was introduced to LLVM IR in #186888. DXILBitcodeWriter
needs to handle this type by generating valid LLVM 3.7 era bitcode,
which is as simple as treating byte equivalently to an integer.
Largely a straight-forward replacement with occasional simplifcations.
For AMDGPU, I assumed that unconditional branches are always uniform and
therefore "simplified"/changed AMDGPUAnnotateUniformValues to only
annotate conditional branches.
Target-specific FastISel only selects conditional branches,
unconditional branches are already handled by the non-target-specific
code.
In #163587 we attempted to generate a dxc-compatible DataLayout when
emitting DXIL, but somehow got it wrong. Update using the DataLayout
that dxc emits verbatim.
Fixes#163882
Move our handling of setting up a compatible triple for DXIL to the
bitcode writer itself, and do the same for the datalayout. This avoids
us needing to temporarily change the triple just to change it back, and
it also allows us to make the datalayout truly compatible, including the
`i8:32` alignment that isn't accepted by modern LLVM's DataLayout.
Fixes#153304
Changes:
- When writing `ConstantExpr` GEPs to DXIL bitcode, the bitcode writer
will use the old Constant Code `CST_CODE_CE_GEP_OLD = 12` instead of the
newer `CST_CODE_CE_GEP = 32` which is interpreted as an undef in DXIL.
Additional context: [CST_CODE_CE_GEP = 12 in
DXC](0c9e75e7e9/include/llvm/Bitcode/LLVMBitCodes.h (L187))
while the same constant code is labeled [CST_CODE_CE_GEP_OLD in
LLVM](65de318d18/llvm/include/llvm/Bitcode/LLVMBitCodes.h (L411))
- Modifies the `PointerTypeAnalysis` to be able to analyze pointer-typed
constants that appear in the operands of instructions so that the
correct type of the `ConstantExpr` GEP is determined and written into
the DXIL bitcode.
- Adds a `PointerTypeAnalysis` test and dxil-dis test to ensure that the
pointer type of `ConstantExpr` GEPs are resolved and `ConstantExpr` GEPs
are written to DXIL bitcode correctly
In addition, this PR also adds a missing call to
`GV.removeDeadConstantUsers()` in the DXILFinalizeLinkage pass, and
removes an unnecessary manual removal of a ConstantExpr in the
DXILFlattenArrays pass.
Fixes#147395
This PR legalizes lifetime intrinsics for DXIL by
- Adding a bitcast for the lifetime intrinsics' pointer operand in
dxil-prepare to ensure it gets cast to an `i8*` when written to DXIL
- Removing the memory attribute from lifetime intrinsics in dxil-prepare
to match DXIL
- Making the DXIL bitcode writer write the base/demangled name of
lifetime intrinsics to the symbol table
- Making lifetime intrinsics an exception to Int64Ops shader flag
analysis (otherwise we get `error: Flags must match usage.` from the
validator)
With this change, some callers get to use StringRef::starts_with.
I'm planning to teach getAsmString to return StringRef also, but
I'ld like to keep that separate from this patch.
commit:
68947342b7
added a new `writeDIFixedPointType` function.
However, `DIFixedPointType` is not supported in DXIL so we need to add a
fail fast case for this to fix the build.
this change fixes a build break introduced by
https://github.com/llvm/llvm-project/pull/129596
The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.
For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.
The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.
1. Fix build break caused by #126772 by adding `writeDISubrangeType`
stub to `DXILBitcodeWriter.cpp`
2. Fix build break caused by #128480 by adding implementation of pure
virtual method `TargetSubtargetInfo::getRegisterInfo`
This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended to be essentially NFC, replacing existing uses of `nocapture`
with `captures(none)` without adding any new analysis capabilities.
Making use of non-`none` values is left for a followup.
Some notes:
* `nocapture` will be upgraded to `captures(none)` by the bitcode
reader.
* `nocapture` will also be upgraded by the textual IR reader. This is to
make it easier to use old IR files and somewhat reduce the test churn in
this PR.
* Helper APIs like `doesNotCapture()` will check for `captures(none)`.
* MLIR import will convert `captures(none)` into an `llvm.nocapture`
attribute. The representation in the LLVM IR dialect should be updated
separately.
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
