LLVM and SPIRV-LLVM-Translator pulldown (WW29) #4092
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
Override the `shouldScalarizeBinop` target lowering hook using the same implementation used in the x86 backend. This causes `extract_vector_elt`s of vector binary ops to be scalarized if the scalarized version would be supported. Differential Revision: https://reviews.llvm.org/D105646
`GeneralizePadTensorOpPattern` might generate `tensor.dim` op so the TensorDialect should be marked legal. This pattern should also transform all `linalg.pad_tensor` ops so mark those as illegal. Those changes are missed from a previous change in https://reviews.llvm.org/D105293 Reviewed By: silvas Differential Revision: https://reviews.llvm.org/D105642
…ing. NFC This parameter controls how much space is reserved for incoming values. There are always going to be 2 incoming values in this case. While there remove the unused std::vector right below. Found while looking at porting this code to RISCV.
The rest of the SOP instructions implicitly set SCC and not suitable for the rematerialization. Differential Revision: https://reviews.llvm.org/D105670
We opt to use unit tests rather than check tests as the lattice/merger code is a small C++ component with a well-defined API. Testing this API via check tests would be far less direct and readable. In addition, as the check tests will only be able to test the API indirectly, the tests may break based on unrelated changes; e.g. changes in linalg. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D104956
AddDiscriminatorsPass is in Legacy PM's O0 pipeline. This patch did the same for NPM O0 pipeline. Reviewed By: aeubanks, MaskRay Differential Revision: https://reviews.llvm.org/D105650
for issue: google/sanitizers#1394 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D104155
Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D105623
In preparation for D104075. Some NFC cleanup, and some test coverage for planned changes.
This reverts commit 0d0cff3. The build is broken with GCC 5.4
… with SH*ADD This patch will show the following optimization by future patches. (mul x imm) -> (SH1ADD x, (SLLI x, bits)) when imm = 2^n + 2. (mul x imm) -> (SH2ADD x, (SLLI x, bits)) when imm = 2^n + 4. (mul x imm) -> (SH3ADD x, (SLLI x, bits)) when imm = 2^n + 8. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D105614
This patch explicitly sets the shadow offset for AMDGPU to match that of X86 on Linux. Reviewed By: vitalybuka https://reviews.llvm.org/D105282
… -O0" This reverts commit 458c230. This broke LLDB buildbot testcase where breakpoint set at start of loop failed to hit. https://lab.llvm.org/buildbot/#/builders/96/builds/9404 https://github.com/llvm/llvm-project/blob/main/lldb/test/API/commands/process/attach/main.cpp#L15 Differential Revision: https://reviews.llvm.org/D105238
When the instruction has imm form and fed by LI, we can remove the redundat LI instruction.
Below is an example:
```
renamable $x5 = LI8 2
renamable $x4 = exact SRD killed renamable $x4, killed renamable $r5, implicit $x5
```
will be converted to:
```
renamable $x5 = LI8 2
renamable $x4 = exact RLDICL killed renamable $x4, 62, 2, implicit killed $x5
```
But when we do this optimization, we forget to remove implicit killed $x5
This bug has caused a lnt case error. This patch is to fix above bug.
Reviewed By: #powerpc, shchenz
Differential Revision: https://reviews.llvm.org/D85288
`-fno-semantic-interposition` was added for GCC in D102453, but some MLIR tests on SystemZ failed with GCC<10.3 due to a bug. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D105453
Add extension macro __riscv_zvlsseg to enable Zvlsseg builtins only with target feature Zvlsseg. Reviewed By: HsiangKai Differential Revision: https://reviews.llvm.org/D105626
To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug- The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
There was an alias between 'simplifycfg' and 'simplify-cfg' in the PassRegistry. That was the original reason for this patch, which effectively removes the alias. This patch also replaces all occurrances of 'simplify-cfg' by 'simplifycfg'. Reason for choosing that form for the name is that it matches the DEBUG_TYPE for the pass, and the legacy PM name and also how it is spelled out in other passes such as 'loop-simplifycfg', and in other options such as 'simplifycfg-merge-cond-stores'. I for some reason the name should be changed to 'simplify-cfg' in the future, then I think such a renaming should be more widely done and not only impacting the PassRegistry. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D105627
It is confusing to have two ways of specifying the same pass
('simple-loop-unswitch' and 'unswitch'). This patch replaces
'unswitch' by 'simple-loop-unswitch' to get a unique identifier.
Using 'simple-loop-unswitch' instead of 'unswitch' also has the
advantage of matching how the pass is named in DEBUG_TYPE etc. So
this makes it a bit more consistent how we refer to the pass in
options such as -passes, -print-after and -debug-only.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D105628
After this change DSE can eliminate malloc + memset and emit calloc. It's https://reviews.llvm.org/D101440 follow-up. Differential Revision: https://reviews.llvm.org/D103009
…eaders FreeBSD's condvar.h (included by user.h in Threading.inc) uses a "struct thread" that conflicts with llvm::thread if both are visible when it's included. So this moves our #include after the FreeBSD code.
This patch changes the DynamicReloc class to store an enum instead
of the overloaded useSymVA member to make it easier to understand
and fix incorrect addends being written in some corner cases. The
change is motivated by a follow-up review that checks the value of
implicit Elf_Rel addends written to the output file.
This patch fixes an incorrect output when using `-z rela` for i386 files
with R_386_GOT32 relocations (not that this really matters since it's an
unsupported configuration).
Storing the relocation expression kind also addresses an incorrect addend
FIXME in ppc64-abs64-dyn.s introduced in D63383.
DynamicReloc now also has a special case for the MIPS TLS relocations
(DynamicReloc::AgainstSymbolWithTargetVA) since the
R_MIPS_TLS_TPREL{32/64} the symbol VA to the GOT for preemptible
symbols. I'm not sure if the symbol value actually should be written
for R_MIPS_TLS_TPREL32, but this patch does not attempt to change
that behaviour.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100490
There used to be many cases where addends for Elf_Rel were not emitted in the final object file (mostly when building for MIPS64 since the input .o files use RELA but the output uses REL). These cases have been fixed since, but this patch adds a check to ensure that the written values are correct. It is based on a previous patch that I added to the CHERI fork of LLD since we were using MIPS64 as a baseline. The work has now almost entirely shifted to RISC-V and Arm Morello (which use Elf_Rela), but I thought it would be useful to upstream our local changes anyway. This patch adds a (hidden) command line flag --check-dynamic-relocations that can be used to enable these checks. It is also on by default in assertions builds for targets that handle all dynamic relocations kinds that LLD can emit in Target::getImplicitAddend(). Currently this is enabled for ARM, MIPS, and I386. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101450
This allows checking dynamic relocation addends for -z rel and --apply-dynamic-relocs output. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101451
I found this missing case with the new --check-dynamic-relocation flag while running the lld tests with --apply-dynamic-relocs enabled by default. This also fixes a broken CHECK in lld/test/ELF/x86-64-gotpc-relax.s: The test wasn't using CHECK-NEXT, so it was passing despite the output actually containing relocations. I am not sure when this changed, but I think this behaviour is correct. Found with D101450 + enabling --apply-dynamic-relocs by default. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101452
I found this missing case with the new --check-dynamic-relocation flag while running the lld tests with --apply-dynamic-relocs enabled by default. This is the same as D101452 just for RISC-V Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101454
This allows checking dynamic relocation addends for -z rel and --apply-dynamic-relocs output. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101455
Enable using of CreateInBounds with element type due to deprecate GetElementPtrInst::CreateInBounds without element type. Original commit: KhronosGroup/SPIRV-LLVM-Translator@fbb53e6
Original commit: KhronosGroup/SPIRV-LLVM-Translator@910aee7
This extension creates support for a __fence keyword to prevent reordering and reassociating operations. Spec: intel#3914 Original commit: KhronosGroup/SPIRV-LLVM-Translator@211c7dc
Make the following classes inherit from SPIRVInstTemplateBase: - SPIRVSelect - SPIRVVectorShuffle - SPIRVCompositeExtract - SPIRVCompositeInsert This allows removing a switch on opcode in SPIRVInstruction.cpp. Fixes KhronosGroup/SPIRV-LLVM-Translator#1072 Original commit: KhronosGroup/SPIRV-LLVM-Translator@fb5ef41
With SPIRVSelect inheriting from SPIRVInstTemplateBase, this can now be handled through the switch default. Original commit: KhronosGroup/SPIRV-LLVM-Translator@b5441a4
It is possible that for a single element Src type size doesn't match memory size to move (for example we copy N elements of one integer array to an address of a first element of another integer array). Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com> Original commit: KhronosGroup/SPIRV-LLVM-Translator@2e57c8f
Signed-off-by: Artem Gindinson <artem.gindinson@intel.com> Original commit: KhronosGroup/SPIRV-LLVM-Translator@fe35522
Due to Windows-specific sporadic translation failures, revert until root cause is identified. This reverts commit 348d3cf97c121cab056331470cf761bad056c03c. Original commit: KhronosGroup/SPIRV-LLVM-Translator@be51424
This extension provides instructions to convert single-precision 32-bit floating-point value to bfloat16 format and vice versa. It doesn't introduce bfloat16 type in SPIR-V, instead instructions below use 16-bit integer type whose bit pattern represents (bitcasted from) a bfloat16 value. Spec: https://github.com/intel/llvm/blob/f587bbfb8a742bd55c80b12e01505ed085a0748f/sycl/doc/extensions/SPIRV/SPV_INTEL_bf16_convert.asciidoc Signed-off-by: Mikhail Lychkov <mikhail.lychkov@intel.com> Original commit: KhronosGroup/SPIRV-LLVM-Translator@c04b226
In a followup commit, an instruction's required capabilities will
depend on its argument types. This does not work with the current
LLVM-to-SPIR-V translation that consists of the following steps:
1. Create the instruction without operands.
2. Add it to the module (which queries the instruction's required
capabilities).
3. Add operands.
Swap steps 2 and 3, such that the instruction is fully constructed
before querying its required capabilities.
Original commit:
KhronosGroup/SPIRV-LLVM-Translator@adc930c
Add support for mapping the SPV_KHR_integer_dot_product extension operations to and from SPIR-V friendly IR. Original commit: KhronosGroup/SPIRV-LLVM-Translator@faea0eb
Update for LLVM commit b00cff5 ("Reapply [IR] Don't accept nullptr as GEP element type", 2021-07-09). Original commit: KhronosGroup/SPIRV-LLVM-Translator@c8aaa5f
cf9a204 to
ec7b002
Compare
|
/summary:run |
|
/summary:run |
To be reverted once we move to NewPM by default.
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@6b16683
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@c8aaa5f