This diff splits out (from LLVMCore) IR printing passes into IRPrinter.
This structure is similar to what we already have for IRReader and
enables us to avoid circular dependencies between LLVMCore and Analysis
(this is a preparation for https://reviews.llvm.org/D137768).
The legacy interface is left unchanged, once the legacy pass manager
is removed (in the future) we will be able to clean it up further.
The bazel build configuration has been updated as well.
Test plan:
1/ Tested the following cmake configurations: static/dynamic linking * lld/gold * clang/gcc
2/ bazel build --config=generic_clang @llvm-project//...
Differential revision: https://reviews.llvm.org/D138081
DXContainer files have a handful of sections that need to be written.
This adds a pass to write the section data into IR globals, and writes
the shader flag data into a global.
The test cases here verify that the shader flags are correctly written
from the IR into the global and emitted to the DXContainer.
This change also fixes a bug in the MCDXContainerWriter, where the size
of the dxbc::ProgramHeader was not being included in the part offset
calcuations. This is verified to be working by the new testcases where
obj2yaml can properly dump part data for parts after the DXIL part.
Resolves issue #57742 (https://github.com/llvm/llvm-project/issues/57742)
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D135793
When DXC prints IR output it adds a bunch of IR comments in a header
that describe the DXIL metadata in a more human-readable format. This
pass will serve that purpose for LLVM by printing out ahead of the IR
printer.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D135802
This adds infrastructural pieces for an analysis to compute the DXIL
shader flags. In this state the analysis can compute two fairly
straightforward feature flags for use of double-precision floating
point values and the DX 11.1 extended double support.
This patch does conflict with D135190, conflicts will be resolved prior
to merging.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D135393
# Conflicts:
# llvm/lib/Target/DirectX/CMakeLists.txt
# llvm/lib/Target/DirectX/DirectXTargetMachine.cpp
Now only DXILTranslateMetadata uses DXILResources, so DXILResourceWrapper is only used by DXILTranslateMetadata.
Once we add lower for createHandle, DXILResourceWrapper will be used in more passes.
Also we can add resource index allocation in DXILResourceWrapper.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D135190
When emit-obj from clang directly, DirectX backend will hit assert caused by not initialize passes for AsmPrinter.
The fix will initialize the passes by calling createPassConfig.
Also ignore global variable which not has section in DXILAsmPrinter::emitGlobalVariable to avoid hit llvm_unreachable in DXILTargetObjectFile::SelectSectionForGlobal.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130856
This is the last piece to bring together writing DXContainer files
containing DXIL through the DirectX backend.
While this change only has one test, all of the tests under
llvm/test/tools/dxil-dis also exercise this code. With this change the
output object file type for the dxil target is now DXContainer. Each of
the existing tests will generate DXContainer files, and the dxil-dis
tests additionally verify that the DXContainers generated are
well-formed and can be parsed by the DirectXShaderCompiler tools.
Depends on D127153 and D127165
Differential Revision: https://reviews.llvm.org/D127166
At the end of the codegen pipeline for DXIL we will emit the DXIL into
a global variable in the Module annotated for the "DXIL" section.
This will be used by the MCDXContainerStreamer to emit the DXIL into a
DXContainer DXIL part.
Other parts of the DXContainer will be constructed similarly by
serializing their values into GlobalVariables.
This will allow DXIL to flow into DXContainers through the normal
MCStreamer flow used in the MC layer.
Depends on D122270
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D125334
A new pass DxilEmitMetadata is added to translate information saved in llvm ir into metadata to match DXIL spec.
Only generate DXIL validator version in this PR.
In llvm ir, validator version is saved in ModuleFlag with "dx.valver" as Key.
!llvm.module.flags = !{!0, !1}
!1 = !{i32 6, !"dx.valver", !2}
!2 = !{i32 1, i32 1}
DXIL validator version has major and minor versions that are specified as named metadata:
!dx.valver = !{!2}
!2 = !{i32 1, i32 7}
Reviewed By: kuhar, beanz
Differential Revision: https://reviews.llvm.org/D125158
A new pass DXILOpLowering was added.
It will scan all llvm intrinsics, create dxil op function if it can map to dxil op function.
Then translate call instructions on the intrinsic into call on dxil op function.
dxil op function will add i32 argument to the begining of args for dxil opcode.
So cannot use setCalledFunction to update the call instruction on intrinsic.
This commit only support sin to start the work.
Reviewed By: kuhar, beanz
Differential Revision: https://reviews.llvm.org/D124805
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
The DXIL Prepare pass handles the IR mutations required to convert
modern LLVM IR into something that more closely resembles LLVM-3.7 IR
so that the DXIL bitcode writer can emit 3.7 IR.
This change adds the codegen pass handling the first two IR
transformations:
* stripping new function attributes
* converting fneg into fsub
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D122081
This is the bare minimum needed to get the DirectX target compiling,
but does not actually do anything.
Reviewed By: pete, rnk, arsenm, jaebaek
Differential Revision: https://reviews.llvm.org/D122080
