LLVM and SPIRV-LLVM-Translator pulldown (WW41) #2602
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…General Dynamic
Add Thread Local Storage support for the 34 bit relocation R_PPC64_GOT_TLSGD_PCREL34 used in General Dynamic.
The compiler will produce code that looks like:
```
pla r3, x@got@tlsgd@pcrel R_PPC64_GOT_TLSGD_PCREL34
bl __tls_get_addr@notoc(x@tlsgd) R_PPC64_TLSGD
R_PPC64_REL24_NOTOC
```
LLD should be able to correctly compute the relocation for R_PPC64_GOT_TLSGD_PCREL34 as well as do the following two relaxations where possible:
General Dynamic to Local Exec:
```
paddi r3, r13, x@tprel
nop
```
and General Dynamic to Initial Exec:
```
pld r3, x@got@tprel@pcrel
add r3, r3, r13
```
Note:
This patch adds support for the PC Relative (no TOC) version of General Dynamic on top of the existing support for the TOC version of General Dynamic.
The ABI does not provide any way to tell by looking only at the relocation `R_PPC64_TLSGD` when it is being used in a TOC instruction sequence or and when it is being used in a no TOC sequence. The TOC sequence should always be 4 byte aligned. This patch adds one to the offset of the relocation when it is being used in a no TOC sequence. In this way LLD can tell by looking at the alignment of the offset of `R_PPC64_TLSGD` whether or not it is being used as part of a TOC or no TOC sequence.
Reviewed By: NeHuang, sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D87318
… in TLS General Dynamic" This reverts commit 7912286.
This reverts commit ef4e971.
This is an alternate fix (see D87835) for a bug where a NaN constant gets wrongly transformed into Infinity via truncation. In this patch, we uniformly convert any SNaN to QNaN while raising 'invalid op'. But we don't have a way to directly specify a 32-bit SNaN value in LLVM IR, so those are always encoded/decoded by calling convert from/to 64-bit hex. See D88664 for a clang fix needed to allow this change. Differential Revision: https://reviews.llvm.org/D88238
This is a partial revert of D62155. Rather than copying libc++ headers into the build directory to be later overwritten by the final headers, use -isystem flag to access libc++ headers during CMake checks. This should address the occasional flake we've seen, especially on Windows builders where CMake fails to overwrite __config with the final version. Differential Revision: https://reviews.llvm.org/D88454
When replacing X == Y ? f(X) : Z with X == Y ? f(Y) : Z, make sure that Y cannot be undef. If it may be undef, we might end up picking a different value for undef in the comparison and the select operand.
This avoids some DenseMap copies when /Zi is in use, and results in fewer data structures. Differential Revision: https://reviews.llvm.org/D88617
This should fix the test failures on the clang win64 bot: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/18830 It has been red since Sept 23-ish. This was subtle to debug. Windows has 'find' and 'sort' utilities in C:\Windows\system32, but they don't support all the same flags as the coreutils programs. I configured the buildbot above with Python 2.7 64-bit (hey, it was set up in 2016). When I installed git for Windows, I opted to add all the Unix utilities that come with git to the system PATH. This is *almost* enough to make the LLVM tests pass, but not quite, because if you use the system PATH, the Windows version of find and sort come first, but the tests that use diff, cmp, etc, will all pass. So only a handful of tests will fail, and with cryptic error messages. The code changed in this CL doesn't work with Python 2. Before Python 3.2, the winreg.OpenKey function did not accept the `access=` keyword argument, the caller was required to pass an unused `reserved` positional argument of 0. The try/except/pass around the OpenKey operation masked this usage error in Python 2. Further, the result of the registry operation has to be converted from unicode to add it to the environment, but that was incidental.
We prefer autodetection here to avoid persisting this configuration in the generated __config header which is shared across targets. Differential Revision: https://reviews.llvm.org/D88694
…4 used in TLS General Dynamic
Add Thread Local Storage support for the 34 bit relocation R_PPC64_GOT_TLSGD_PCREL34 used in General Dynamic.
The compiler will produce code that looks like:
```
pla r3, x@got@tlsgd@pcrel R_PPC64_GOT_TLSGD_PCREL34
bl __tls_get_addr@notoc(x@tlsgd) R_PPC64_TLSGD
R_PPC64_REL24_NOTOC
```
LLD should be able to correctly compute the relocation for R_PPC64_GOT_TLSGD_PCREL34 as well as do the following two relaxations where possible:
General Dynamic to Local Exec:
```
paddi r3, r13, x@tprel
nop
```
and General Dynamic to Initial Exec:
```
pld r3, x@got@tprel@pcrel
add r3, r3, r13
```
Note:
This patch adds support for the PC Relative (no TOC) version of General Dynamic on top of the existing support for the TOC version of General Dynamic.
The ABI does not provide any way to tell by looking only at the relocation `R_PPC64_TLSGD` when it is being used in a TOC instruction sequence or and when it is being used in a no TOC sequence. The TOC sequence should always be 4 byte aligned. This patch adds one to the offset of the relocation when it is being used in a no TOC sequence. In this way LLD can tell by looking at the alignment of the offset of `R_PPC64_TLSGD` whether or not it is being used as part of a TOC or no TOC sequence.
Reviewed By: NeHuang, sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D87318
Fix premature decision in the presence of type-dependent expression operands on whether AltiVec vector initializations from single expressions are "splat" operations. Verify that the instantiation is able to determine the correct cast semantics for both the scalar type and the vector type case. Note that, because the change only affects the single-expression case (and the target type is an AltiVec-style vector type), the replacement of a parenthesized list with a parenthesized expression does not change the semantics of the program in a program-observable manner. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D88526
…ctors. Truncating to v8i8 is a case where we want to split the source but also generate intermediate truncates to reduce the size of the source vector before truncating down to v8i8. This implements the same strategy as what SelectionDAG does, but I'm not certain where if anywhere in generic code it should live. Use it for legalization of v8s8 = G_ICMP v8s32. Differential Revision: https://reviews.llvm.org/D88191
The script's shebang wants Python 3, so we use FindPython3. The
original code didn't work when an unversioned python was not available.
This is explicitly allowed in PEP 394. ("Distributors may choose to set
the behavior of the python command as follows: python2, python3, not
provide python command, allow python to be configurable by an end user
or a system administrator.")
Also I think it's actually required, so let the configuration fail if we
can't find it.
Lastly remove the shebang, since the script is only run via interpreter
and doesn't have the executable bit set anyway.
Reviewed By: jvesely
Differential Revision: https://reviews.llvm.org/D88366
Differential Revision: https://reviews.llvm.org/D88584
…together. There's no need for any difference between these.
This seems to fail on ubuntu 18.04.5 with Clang 9 due to: Error output: error: Couldn't lookup symbols: std::__1::default_delete<int>::operator()(int) const
Before this patch /summary was crashing with some .PCH.OBJ files, because tpiMap[srcIdx++] was reading at the wrong location. When the TpiSource depends on a .PCH.OBJ file, the types should be offset by the previously merged PCH.OBJ set of indices. Differential Revision: https://reviews.llvm.org/D88678
Accidentally pushed this.
No need to be different here for the vast majority of rules.
CONFLICT (content): Merge conflict in libclc/generic/lib/gen_convert.py CONFLICT (content): Merge conflict in libclc/CMakeLists.txt
Partially refactoring, partially fixing a bug. - We shouldn't use TB(N)ZX unless the bit number is >= 32 - We can fold more than xor using emitTestBit Also remove a check which isn't relevant anymore + update tests. Rename select-brcond-of-not.mir to select-brcond-of-binop.mir, since it now tests more than just G_XOR. Differential Revision: https://reviews.llvm.org/D88702
Similar to the FP case in `AArch64TargetLowering::LowerBR_CC`. Instead of emitting the csets + a tbnz, just emit a compare + bcc (or two bccs, depending on the condition code) This improves cases like this: https://godbolt.org/z/v8hebx This is a 0.1% geomean code size improvement for CTMark at -O3. Differential Revision: https://reviews.llvm.org/D88624
Tweak binary->decimal conversions to avoid an integer multiplication in a hot loop to improve readability and get a minor (~5%) speed-up. Use native integer division by constants for more readability, too, since current build compilers seem to optimize it correctly now. Delete the now needless temporary work-around facility in Common/unsigned-const-division.h. Differential revision: https://reviews.llvm.org/D88604
Allows the creation of real SOP1 instructions with assembler mnemonics that differ from their pseudo-instruction mnemonics. The default behavior keeps the mnemonics matching. Corrects a subtarget label typo in a comment. Authored By: Joe_Nash Differential Revision: https://reviews.llvm.org/D88708
We were converting the non-integral store into a integer store which is not legal.
CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/Clang.cpp
The build log did not contain the llvm-project repository revision being built for `BUILD_EXTERNAL=0` builds. Add it to ease debugging of build failures.
* Handle @llvm.memset.* with non-constant arguments There is no SPIR-V counterpart for @llvm.memset.* intrinsic. Cases with constant value and length arguments are emulated via "storing" a constant array to the destination. For other cases we wrap the intrinsic in @spirv.llvm_memset_* function and expand the intrinsic to a loop via expandMemSetAsLoop() from llvm/Transforms/Utils/LowerMemIntrinsics.h. During reverse translation from SPIR-V to LLVM IR we can detect @spirv.llvm_memset_* and replace it with @llvm.memset. Signed-off-by: Alexey Sotkin <[email protected]> Co-authored-by: Sven van Haastregt <[email protected]>
The OpenCL SPIR-V Environment Specification seems to allow corresponding instruction.
Propagate the test change from LLVM commit 55f9f87 ("Reapply Revert "RegAllocFast: Rewrite and improve"", 2020-09-21).
Previously APInt constants were being stored into uint64_t value with following encoding/decoding. Now they are being packed into SPIRVWords array directly. Signed-off-by: Dmitry Sidorov <[email protected]>
Renamed the pass to OCLToSPIRV: the problem with the old name is that it doesn't represent actual pass content: it handles not only OpenCL C 2.0 built-in functions, but also OpenCL C 1.2 built-in functions, acting like an adapter between OpenCL C representation and SPIR-V friendly IR representation. Also updated some comments to reflect that.
Since KhronosGroup/SPIRV-LLVM-Translator@6ceea97 this pass only handles input files coming out OpenCL C++ 2.1, which technically doesn't exists and therefore this should be a dead code. Additionally: most of the pass functionality (except sub-group barrier handling) is untested and duplicated in OCLToSPIRV pass.
Do not translate the llvm.global_ctors and llvm.global_dtors variables to SPIR-V when the function pointers extension is not enabled, because we currently cannot represent the variable without the function pointers extension.
SPIR-V 1.1 adds the Initializer Execution Mode for entry points. Set this execution mode for entry points listed in the llvm.global_ctors variable.
Reconstruct a llvm.global_ctors variable for entry points with the Initializer Execution Mode.
The Initializer and Finalizer Execution Modes were missing before SPIR-V 1.1.
Added possibility to emit SPIR-V friendly IR instead of OpenCL-C-like mangled function names for instructions from OpenCL extended instruction set.
vmaksimo
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
Fznamznon,
mdtoguchi and
premanandrao
as code owners
|
/summary:run |
bader
approved these changes
Oct 8, 2020
jsji
pushed a commit
that referenced
this pull request
Jun 27, 2024
Required after llvm/llvm-project@dc726c340392d: Reapply#4 "[RemoveDIs] Load into new debug info format by default in LLVM Signed-off-by: Sidorov, Dmitry <[email protected]> Original commit: KhronosGroup/SPIRV-LLVM-Translator@338a37ef59ded4f
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM: llvm/llvm-project@e372c1d7624e
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@f33b946