LLVM and SPIRV-LLVM-translator pull down #993
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
Our out-of-tree custom aliasing solution for the HPC# Burst compiler here at Unity makes use of the `ExternalAAwrapperPass` infrastructure to insert our custom aliasing resolution into the core of LLVM. This is great for all cases except for function inlining, where because `createLegacyPMAAResults` does not make use of `ExternalAAWrapperPass`, when we have a definite no-alias result within a function it won't be propagated to the calling function during inlining. This commit just rectifies this oversight by adding the missing dependency. Differential Revision: https://reviews.llvm.org/D71348
This is needed to consume mlir after it has been installed of the source tree. Without this, consuming mlir results a build error. Differential Revision: https://reviews.llvm.org/D72232
Differential Revision: https://reviews.llvm.org/D72047
I've added a few more debug messages to MVETailPredication because I wanted to trace better which instructions are added/removed. And while I was at it, I factored out one function which I thought was clearer, and have added some comments to describe better the flow between MVETailPredication and ARMLowOverheadLoops. Differential Revision: https://reviews.llvm.org/D71549
Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
The checkGetOrParseLineTableEmitsError function could end up generating both recoverable and unrecoverable errors, but it is only intended for handling the latter. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D72156
…BeforeCatch/BeforeElse
Summary:
Found a bug introduced with BraceWrappingFlags AfterControlStatement MultiLine. This feature conflicts with the existing BeforeCatch and BeforeElse flags.
For example, our team uses BeforeElse.
if (foo ||
bar) {
doSomething();
}
else {
doSomethingElse();
}
If we enable MultiLine (which we'd really love to do) we expect it to work like this:
if (foo ||
bar)
{
doSomething();
}
else {
doSomethingElse();
}
What we actually get is:
if (foo ||
bar)
{
doSomething();
}
else
{
doSomethingElse();
}
Reviewers: MyDeveloperDay, Bouska, mitchell-stellar
Patch by: pastey
Subscribers: Bouska, cfe-commits
Tags: clang
Differential Revision: https://reviews.llvm.org/D71939
Summary: This diff reimplements getStridesAndOffset in a significantly simpler way by operating on the AffineExpr and calling into simplifyAffineExpr instead of rolling its own saturating arithmetic. As a consequence it becomes quite simple to extend the behavior of getStridesAndOffset to encompass more cases by manipulating the AffineExpr more directly. The divisions are still filtered out and continue to yield fully dynamic strides. Simplifying the divisions is left for a later time if compelling use cases arise. Relevant tests are added. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72098
This assumed a 32-bit extract size, which would produce invalid copies with 64-bit extracts. Handle the easy case. Ideally we would have a way to get the proper subreg index for any 32-bit offset, but there should probably be a tablegenerated way of getting the subreg index for any size and offset.
orig_*ax logic is Linux-specific, and was never used on NetBSD. In fact, its support seems to be a dead code entirely. Differential Revision: https://reviews.llvm.org/D72195
Summary: Due to a copy-paste error in the isel patterns, the predicated version of this intrinsic was expanding to the `VMAXNMT.F32` instruction instead of `VMAXNMT.F16`. Similarly for vminnm. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72269
Summary: The ACLE intrinsics with `gather_base` or `scatter_base` in the name are wrappers on the MVE load/store instructions that take a vector of base addresses and an immediate offset. The immediate offset can be up to 127 times the alignment unit, and it can be positive or negative. At the MC layer, we got that right. But in the Sema error checking for the wrapping intrinsics, the offset was erroneously constrained to be positive. To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that defines the intrinsics. But that causes integer literals like `0xfffffffffffffe04` to appear in the autogenerated calls to `SemaBuiltinConstantArgRange`, which provokes a compiler warning because that's out of the non-overflowing range of an `int64_t`. So I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead. Updated the tests of the Sema checks themselves, and also adjusted a random sample of the CodeGen tests to actually use negative offsets and prove they get all the way through code generation without causing a crash. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72268
Summary: Running an end-to-end test last week I noticed that a lot of the ACLE intrinsics that operate differently on vectors of signed and unsigned integers were ending up generating the signed version of the instruction unconditionally. This is because the IR intrinsics had no way to distinguish signed from unsigned: the LLVM type system just calls them both `v8i16` (or whatever), so you need either separate intrinsics for signed and unsigned, or a flag parameter that tells ISel which one to choose. This patch fixes all the problems of that kind that I've noticed, by adding an i32 flag parameter to many of the IR intrinsics which is set to 1 for unsigned (matching the existing practice in cases where we got it right), and conditioning all the isel patterns on that flag. So the fundamental change is in `IntrinsicsARM.td`, changing the low-level IR intrinsics API; there are knock-on changes in `arm_mve.td` (adjusting code gen for the ACLE intrinsics to use the modified API) and in `ARMInstrMVE.td` (adjusting isel to expect the new unsigned flags). The rest of this patch is boringly updating tests. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72270
Add "unreachable" default cases like we do for the other switch()s in X86MCInstLower::Lower
… NFCI. Add "unreachable" default case to AMDGPUTargetStreamer::getArchNameFromElfMach
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D72210
This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912 Recomitted after fixing the warnings it created.
SUMMARY: We currently emit a reference for function address constants as labels; for example: foo_ptr: .long foo however, there may be no such label in the case where the function is undefined. Although the label exists when the function is defined, we will (to be consistent) also use a csect reference in that case. Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L Subscribers: cebowleratibm, wuzish, nemanjai Differential Revision: https://reviews.llvm.org/D71144
We were previously unconditionally using the ARM::TRAP opcode, even under Thumb. My understanding is that these are essentially the same thing (they both result in a trap under Thumb), but the ARM::TRAP opcode is marked as requiring IsARM, so it is more correct to use ARM::tTRAP. Differential Revision: https://reviews.llvm.org/D72075
The segmented stack lowering code appears to be using ARM opcodes under Thumb2. The MRC opcode will be the same for Thumb and ARM, but t2LDR seems wrong. Either way, using the correct thumb vs arm opcodes is more correct. Differential Revision: https://reviews.llvm.org/D72074
Summary: This patch adds a virtual destructor to the Command class. Reviewers: sivachandra Subscribers: mgorny, MaskRay, libc-commits Tags: #libc-project Differential Revision: https://reviews.llvm.org/D72253
SUMMARY: We currently emit a reference for function address constants as labels; for example: foo_ptr: .long foo however, there may be no such label in the case where the function is undefined. Although the label exists when the function is defined, we will (to be consistent) also use a csect reference in that case. Address one comment https://reviews.llvm.org/D71144#inline-653255 Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L Subscribers: cebowleratibm, wuzish, nemanjai Differential Revision: https://reviews.llvm.org/D71144
Python was the last remaining "optional" dependency for LLDB. This moves the code to find Python into FindPythonInterpAndLibs using the same principles as FindCursesAndPanel. Differential revision: https://reviews.llvm.org/D72107
Use castAs<> instead of getAs<> since we know that the pointer will be valid (and is dereferenced immediately below).
Use cast<> instead of dyn_cast<> since we know that the pointer should be valid (and is dereferenced immediately below in the getSignature call).
Silence (clang/MSVC) static analyzer warnings that the fragment data may either write out of bounds of the local array or reference uninitialized data.
D59275 added the following clause to Symbol::includeInDynsym()
if (isUndefWeak() && Config->Pie && SharedFiles.empty())
return false;
D59549 explored the possibility to generalize it for -no-pie.
GNU ld's rules are architecture dependent and partly controlled by -z
{,no-}dynamic-undefined-weak. Our attempts to mimic its rules are
actually half-baked and don't provide perceivable benefits (it can save
a few more weak undefined symbols in .dynsym in a -static-pie
executable). Let's just delete the rule for simplicity. We will expect
cosmetic inconsistencies with ld.bfd in certain -static-pie scenarios.
This permits a simplification in D71795.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D71794
Weak undefined symbols are preemptible after D71794.
if (sym.isPreemptible)
return false;
if (!config->isPic)
return true;
// isPic means includeInDynsym is true after D71794.
...
// We can delete this if because it can never be true.
if (sym.isUndefWeak)
return true;
Differential Revision: https://reviews.llvm.org/D71795
As discussed heavily in the original review (D70157), there's a need for the compiler to be able to selective suppress padding (either nop or prefix) to respect assumptions about the meaning of labels and instructions in generated code. Rather than wait for syntax to be finalized - which appears to be a very slow process - this patch focuses on the compiler use case and *only* worries about the integrated assembler. To my knowledge, this covers all cases mentioned to date for clang/JIT support. For testing purposes, I wired it up so that if the integrated assembler was using autopadding for branch alignment (e.g. enabled at command line) then the textual assembly output would contain a comment for each location where padding was enabled or disabled. This seemed like the least painful choice overall. Note that the result of this patch effective disables the jcc errata mitigation for many constructs (statepoints, implicit null checks, xray, etc...) which is non ideal. It is at least *correct* and should allow us to enable the mitigation for the compiler. Once that's done, and a few other items are worked through, we probably want to come back to this an explore a bundling based approach instead so that we can pad instructions while keeping labels in the right place. Differential Revision: https://reviews.llvm.org/D72303
…double. We have to do an intermediate jump to a GPR to make the cast. Fixes PR43750.
…in 64-bit mode For v4i64->v4f32 uint_to_fp on pre-avx targets where v4i64 isn't legal we create to v2i64->v2f32 uint_to_fp that need to be shuffled together. Our codegen for v2i64->v2f32 involves detecting if the number is larger than (2^31 - 1), if so we do a special divison by 2 so we can do a signed conversion which we need to scalarize, then do a multiply by 2 at the end if we divided earlier. When v4i64 isn't legal we need to split the checking for a larger number and dividing by 2 into two v2i64 vectors. The scalar part can extract the 4 i64 values from those 4 splits. But we can reassemble the 4 scalar f32 results directly into a single v432 vector. Then we just need to combine the fixup indications from the 2 halves and we can do the final multiply by 2 fixup on all 4 values if needed at once using a single v4f32 blend and v4f32 fadd. Differential Revision: https://reviews.llvm.org/D72368
Summary: This diff adds lowering of the linalg.reshape op to LLVM. A new descriptor is created with fields initialized as follows: 1. allocatedPTr, alignedPtr and offset are copied from the source descriptor 2. sizes are copied from the static destination shape 3. strides are copied from the static strides collected with `getStridesAndOffset` Only the static case in which the target view conforms to strided memref semantics is supported. Other cases are left for future work and will be added on a per-need basis. Reviewers: ftynse, mravishankar Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72316
…d into a new class AliasState. Summary: This reduces the complexity of ModuleState and simplifies the code. A future revision will mold ModuleState into something that can be used by users for caching of printer state, as well as for implementing printAsOperand style methods. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72292
…g-indentation`. Because Windows build uses by default `fdelayed-template-parsing` we cannot have a test where we don't instantiate the template. Please see D72333.
Summary: Right now the path for each lib in whole_archive_link when MSVC is used as the compiler is not a full path - and it's not even the correct path when VS is used to build. This patch sets the lib path to a full path using CMAKE_CFG_INTDIR which means the path will be correct regardless of whether ninja, make or VS is used and it will always be a full path. Reviewers: denis13, jpienaar Reviewed By: jpienaar Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, llvm-commits, asmith Tags: #llvm Differential Revision: https://reviews.llvm.org/D72403
Summary: Detect a run of memory tagging instructions for adjacent stack frame slots, and replace them with a shorter instruction sequence * replace STG + STG with ST2G * replace STGloop + STGloop with STGloop This code needs to run when stack slot offsets are already known, but before FrameIndex operands in STG instructions are eliminated; that's the reason for the new hook in PrologueEpilogue. This change modifies STGloop and STZGloop pseudos to take the size as an immediate integer operand, and base address as a FI operand when possible. This is needed to simplify recognizing an STGloop instruction as operating on a stack slot post-regalloc. This improves memtag code size by ~0.25%, and it looks like an additional ~0.1% is possible by rearranging the stack frame such that consecutive STG instructions reference adjacent slots (patch pending). Reviewers: pcc, ostannard Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70286
This matcher matches any node and at the same time executes all its inner matchers to produce any possbile result bindings. This is useful when a user wants certain supplementary information that's not always present along with the main match result.
Summary: Pretty self-evident. This example was missing an lparen. Added it, and fixed up the ASCII art. Patch by Nick Black <[email protected]> Reviewers: pcc Reviewed By: pcc Subscribers: tejohnson, mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D70765
See D72361 for discussion.
Summary: Rewrite alloc, memref_cast, std.view into allo, std.view by droping memref_cast. Reviewers: nicolasvasilache Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72379
The current SWIG extensions for the string conversion operator is Python specific because it uses the PythonObjects. This means that the code cannot be reused for other SWIG supported languages such as Lua. This reimplements the extensions in a more generic way that can be reused. Differential revision: https://reviews.llvm.org/D72377
It looks like my patch breaks the sanitizer-windows build: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/56324 This reverts commit ead8159.
Just like Python, Lua should only be auto-enabled if SWIG is found as well. This moves the logic of finding SWIG and Lua as a whole into a new CMake package.
…_pulldown Build passed
The particular order of !"llvm.loop.parallel_access_indices" metadata
operands being non-deterministic and irrelevant, it makes sense to
alleviate the LIT tests from the corresponding restriction on the index
groups' order.
E.g. both of the below scenarios would now pass the tests:
!0 = !{!"llvm.loop.parallel_access_indices", !1, !2}
OR
!0 = !{!"llvm.loop.parallel_access_indices", !2, !1}
The tweaks of SPIRV types' checks fall into the same category.
Signed-off-by: Artem Gindinson <[email protected]>
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.
No description provided.