[DirectX] Lower ops after translating metadata (#120157)

Move the DXILOpLoweringPass after DXILTranslateMetadata, and add asserts
in DXILShaderFlags to ensure it isn't scheduled after op lowering.

[DirectX] Lower ops after translating metadata (#120157)

Move the DXILOpLoweringPass after DXILTranslateMetadata, and add asserts
in DXILShaderFlags to ensure it isn't scheduled after op lowering. This
will allow us to rely on DirectX intrinsics in the shader flags analysis
rather than having to recover information from lowered operations.

Fixes #120119.

show more ...

[DirectX] Introduce the DXILResourceAccess pass (#116726)

This pass transforms resource access via `llvm.dx.resource.getpointer`
into buffer loads and stores.

Fixes #114848.

[DirectX] Run DXILFinalizeLinkage earlier in the pipeline (#117950)

This moves DXILFinalizeLinkage before the DXIL op lowering passes so
that it doesn't end up internalizing any of the `dx.op.*` fu

[DirectX] Run DXILFinalizeLinkage earlier in the pipeline (#117950)

This moves DXILFinalizeLinkage before the DXIL op lowering passes so
that it doesn't end up internalizing any of the `dx.op.*` functions.
This also exposed a bug when the pass is run on a module with intrinsics
in them - marking the intrinsics as internal will fail the validator.

Fixes #117761

show more ...

Fixed un-renamed CodeGenTargetMachineImpl Intheritances in Experimental Targets (#116290)

This PR fixes a set of build issues with experimental targets happened
in result of merging #111234 to mast

Fixed un-renamed CodeGenTargetMachineImpl Intheritances in Experimental Targets (#116290)

This PR fixes a set of build issues with experimental targets happened
in result of merging #111234 to master.

show more ...

Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/

Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.

cc @arsenm @aeubanks

show more ...

[DirectX] Flatten arrays (#114332)

- Relevant piece is `DXILFlattenArrays.cpp`
- Loads and Store Instruction visits are just for finding
GetElementPtrConstantExpr and splitting them.
- Allocas

[DirectX] Flatten arrays (#114332)

- Relevant piece is `DXILFlattenArrays.cpp`
- Loads and Store Instruction visits are just for finding
GetElementPtrConstantExpr and splitting them.
- Allocas needed to be replaced with flattened allocas.
- Global arrays were similar to allocas. Only interesting piece here is
around initializers.
- Most of the work went into building correct GEP chains. The approach
here was a recursive strategy via `recursivelyCollectGEPs`.
- All intermediary GEPs get marked for deletion and only the leaf GEPs
get updated with the new index.

fixes [89646](https://github.com/llvm/llvm-project/issues/89646)

show more ...

Scalarizer: Replace cl::opts with pass parameters (#110645)

Preserve the existing defaults (although load-store defaulting
to false is a really bad one). Also migrate DirectX tests to new PM.

[DirectX] Data Scalarization of Vectors in Global Scope (#110029)

This change adds a pass to scalarize vectors in global scope into
arrays.

There are three distinct parts
1. find the globals th

[DirectX] Data Scalarization of Vectors in Global Scope (#110029)

This change adds a pass to scalarize vectors in global scope into
arrays.

There are three distinct parts
1. find the globals that need to be updated and define what the new type
should be
2. initialize that new type and copy over all the right attributes over
from the old type.
3. Use the instruction visitor pattern to update the loads, stores, and
geps for the layout of the new data structure.

resolves https://github.com/llvm/llvm-project/issues/107920

show more ...

[LegacyPM][DirectX] Add legacy scalarizer back for use in the DirectX backend (#107427)

As discussed in this
[proposal](https://github.com/llvm/wg-hlsl/pull/62/files?short_path=ac6e592#diff-ac6e592

[LegacyPM][DirectX] Add legacy scalarizer back for use in the DirectX backend (#107427)

As discussed in this
[proposal](https://github.com/llvm/wg-hlsl/pull/62/files?short_path=ac6e592#diff-ac6e59276afe8016e307eedc5c835f534c0cb353707760b44df0fa9d905a5cf8).
We had to bring back the legacy pass manager interface for the
scalarizer pass. Two reasons for this:
1. The DirectX backend is still using the legacy pass manager
2. The new PM isn't hooked up in clang yet via `BackendUtil.cpp`'s
`AddEmitPasses` That means even if we add a `buildCodeGenPipeline` we
won't be able to benefit from the new pass manager's scalarizer pass
interface.

The remaining changes are hooking up the scalarizer pass to the DirectX
backend, updating the DirectX test cases,
and allowing the `optdriver` to not block the legacy invocation of the
scalarizer pass.

Future work still needs to be done to allow the scalarizer pass to
handle target specific intrinsics.

closes #105178

show more ...

[DirectX] Register a few DXIL passes with the new PM

This wires up dxil-op-lower, dxil-intrinsic-expansion, dxil-translate-metadata,
and dxil-pretty-printer to the new pass manager, both as a matter

[DirectX] Register a few DXIL passes with the new PM

This wires up dxil-op-lower, dxil-intrinsic-expansion, dxil-translate-metadata,
and dxil-pretty-printer to the new pass manager, both as a matter of future
proofing the backend and so that they can be used more flexibly in tests.

A few arbitrary tests are updated in order to test the new PM path, and we drop
the "print-dxil-resource-md" pass since it's redundant with the pretty printer.

Pull Request: https://github.com/llvm/llvm-project/pull/104250

show more ...

[HLSL] Change default linkage of HLSL functions to internal (#95331)

An HLSL function has internal linkage by default unless it is:
1. shader entry point function
2. marked with the `export` keywo

[HLSL] Change default linkage of HLSL functions to internal (#95331)

An HLSL function has internal linkage by default unless it is:
1. shader entry point function
2. marked with the `export` keyword
(https://github.com/llvm/llvm-project/issues/92812)
3. patch constant function (not implemented yet)

This PR adds a link-time pass `DXILFinalizeLinkage` that updates the
linkage of functions to make sure only shader entry points and exported
functions are visible from the module (have _program linkage_). All
other functions will be updated to have internal linkage.

Related spec update: microsoft/hlsl-specs#295

Fixes #llvm/llvm-project#92071

show more ...

[DirectX] Rename backend DXIL resource analysis passes to DXILResourceMD*. NFC

These passes will be replaced soon as we move to the target extension based
resource handling in the DirectX backend, b

[DirectX] Rename backend DXIL resource analysis passes to DXILResourceMD*. NFC

These passes will be replaced soon as we move to the target extension based
resource handling in the DirectX backend, but removing them now before the
replacement stuff is all up and running would be very disruptive. However, we
do need to move these passes out of the way to avoid symbol conflicts with the
new DXILResourceAnalysis in the Analysis library.

Note: I tried an even simpler hack in #100698 but it doesn't really work. A
rename is the most expedient path forward here.

Pull Request: https://github.com/llvm/llvm-project/pull/101393

show more ...

Reapply [IR] Lazily initialize the class to pass name mapping (NFC) (#96321) (#96462)

On MSVC the `this` uses inside `decltype` require a lambda capture. On
clang they result in an unused capture w

Reapply [IR] Lazily initialize the class to pass name mapping (NFC) (#96321) (#96462)

On MSVC the `this` uses inside `decltype` require a lambda capture. On
clang they result in an unused capture warning instead. Add the capture
and suppress the warning with `(void)this`.

-----

Initializing this map is somewhat expensive (especially for O0), so we
currently only do it if certain flags are used. I would like to make use
of it for crash dumps (#96078), where we don't know in advance whether
it will be needed or not.

This patch changes the initialization to a lazy approach, where a
callback is registered that does the actual initialization. The
callbacks will be run the first time the pass name is requested.

This way there is no compile-time impact if the mapping is not used.

show more ...

Revert "[IR] Lazily initialize the class to pass name mapping (NFC) (#96321)"

My attempt to fix the Windows build made things worse,
revert entirely for now.

This reverts commit e7137f2fed5cfee822a

Revert "[IR] Lazily initialize the class to pass name mapping (NFC) (#96321)"

My attempt to fix the Windows build made things worse,
revert entirely for now.

This reverts commit e7137f2fed5cfee822ae3c4c6d39188adb59a16c.
This reverts commit 6eaf204dbb0a6a81cddfd02f625c130f7bb1aae5.
This reverts commit 957dc4366dd2ce9d5d2991c3ad76bbf438e9954e.

show more ...

[DirectX] Fix DirectXTargetMachine after #96321

[DirectX] remove string function attribute DXIL not allowed (#90778)

Remove string function attribute other than
"waveops-include-helper-lanes" and "fp32-denorm-mode".

Move DXILPrepareModulePass

[DirectX] remove string function attribute DXIL not allowed (#90778)

Remove string function attribute other than
"waveops-include-helper-lanes" and "fp32-denorm-mode".

Move DXILPrepareModulePass after DXILTranslateMetadataPass since
DXILTranslateMetadataPass needs to use attribute like hlsl.numthreads.

Fixes #90773

show more ...

[NewPM][DirectX] Add DirectXPassRegistry.def NFCI (#86242)

Prepare migration for dag-isel

[DXIL] `exp`, `any`, `lerp`, & `rcp` Intrinsic Lowering (#84526)

This change implements lowering for #70076, #70100, #70072, & #70102
`CGBuiltin.cpp` - - simplify `lerp` intrinsic
`IntrinsicsDire

[DXIL] `exp`, `any`, `lerp`, & `rcp` Intrinsic Lowering (#84526)

This change implements lowering for #70076, #70100, #70072, & #70102
`CGBuiltin.cpp` - - simplify `lerp` intrinsic
`IntrinsicsDirectX.td` - simplify `lerp` intrinsic
`SemaChecking.cpp` - remove unnecessary check
`DXILIntrinsicExpansion.*` - add intrinsic to instruction expansion
cases
`DXILOpLowering.cpp` - make sure `DXILIntrinsicExpansion` happens first
`DirectX.h` - changes to support new pass
`DirectXTargetMachine.cpp` - changes to support new pass

Why `any`, and `lerp` as instruction expansion just for DXIL?
- SPIR-V there is an
[OpAny](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#OpAny)
- SPIR-V has a GLSL lerp extension via
[Fmix](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#FMix)

Why `exp` instruction expansion?
- We have an `exp2` opcode and `exp` reuses that opcode. So instruction
expansion is a convenient way to do preprocessing.
- Further SPIR-V has a GLSL exp extension via
[Exp](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#Exp)
and
[Exp2](https://registry.khronos.org/SPIR-V/specs/1.0/GLSL.std.450.html#Exp2)

Why `rcp` as instruction expansion?
This one is a bit of the odd man out and might have to move to
`cgbuiltins` when we better understand SPIRV requirements. However I
included it because it seems like [fast math mode has an AllowRecip
flag](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_fp_fast_math_mode)
which lets you compute the reciprocal without performing the division.
We don't have that in DXIL so thought to include it.

show more ...

[CodeGen] Add flag to populate target pass names (#76328)

`print-pipeline-passes` can show target pass names.

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future chang

[NFC][CodeGen] Change CodeGenOpt::Level/CodeGenFileType into enum classes (#66295)

This will make it easy for callers to see issues with and fix up calls
to createTargetMachine after a future change to the params of
TargetMachine.

This matches other nearby enums.

For downstream users, this should be a fairly straightforward
replacement,
e.g. s/CodeGenOpt::Aggressive/CodeGenOptLevel::Aggressive
or s/CGFT_/CodeGenFileType::

show more ...

[DirectX] Only embed dxil when writing object files

When emitting assembly we don't particularly want the binary DXIL
embedded in the output. This was mostly there for testing purposes, so
we update

[DirectX] Only embed dxil when writing object files

When emitting assembly we don't particularly want the binary DXIL
embedded in the output. This was mostly there for testing purposes, so
we update those tests to run the test directly using `opt` and
restrict the -dxil-embed and -dxil-globals passes to running normally
only in the case where we're trying to emit a DXContainer.

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

show more ...

[DirectX backend] Remove unused bitcode block for dxil

DXIL doesn't need uselist strtab and symtab blocks which are not supported by llvm3.7 bitcode.

Differential Revision: https://reviews.llvm.or

[DirectX backend] Remove unused bitcode block for dxil

DXIL doesn't need uselist strtab and symtab blocks which are not supported by llvm3.7 bitcode.

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

show more ...

CodeGen/CommandFlags: Convert Optional to std::optional

Convert Optional<CodeModel> to std::optional<CodeModel>

[NFC][DirectX backend] Update header to fix build error.

Fix build error caused by createPrintModulePass moving to diffrent
header.