LLVM and SPIRV-LLVM-Translator pulldown (WW07-08) with disabled NewPM by default #3266
Conversation
This file contains 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
https://reviews.llvm.org/D89662 turned this off at dfsan_init. dfsan_flush also needs to turn it off. W/o this a program may get more and more memory usage after hours. Reviewed-by: morehouse Differential Revision: https://reviews.llvm.org/D96569
…ions for fixed vectors. Unlike scalable vectors, I'm only using a ComplexPattern for the immediate itself. The vmv_v_x is matched explicitly. We igore the VL argument when matching a binary operator, but we do check it when matching splat directly. I left out tests for vXi64 as they fail on rv32 right now. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D96365
I believe I've covered all orderings of splat operands here. Better canonicalization in lowering might help reduce this. I did not handle the immediate adjustments needed for set(u)gt/set(u)lt. Testing here is limited to byte types because the scalable vector type used for masks for the store is calculated assuming 8 byte elements. But for the setcc its based on the element count of the container type for the setcc input. So they don't agree. We'll need to enhanced D96352 to handle this I think. Differential Revision: https://reviews.llvm.org/D96443
Modules can be used to augment clangd's behaviours in various features. Differential Revision: https://reviews.llvm.org/D96244
Migrate the translation of the OpenMP dialect operations to LLVM IR to the new dialect-based mechanism. Depends On D96503 Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96504
The gold LTO plugin uses a set of hooks to implements emit-llvm and capture intermediate file generated during LTO. The hooks are called by each lto backend thread with a taskID as argument to differentiate between threads and tasks. Currently, all threads are overwriting the same file which results into only the intermediate output of the last backend thread to be preserved. This diff encodes the taskID into the filename. Reviewed By: tejohnson, wenlei Differential Revision: https://reviews.llvm.org/D96173
CONFLICT (content): Merge conflict in llvm/tools/opt/opt.cpp
Windows' memory unmapping has to be explicit, there is no madvise. Similarly, re-mapping memory has to be explicit as well. This patch implements a basic method for remapping memory which was previously returned to the OS on Windows. Patch by Matthew G. McGovern and Jordyn Puryear
explicitly emitting retainRV or claimRV calls in the IR Background: This fixes a longstanding problem where llvm breaks ARC's autorelease optimization (see the link below) by separating calls from the marker instructions or retainRV/claimRV calls. The backend changes are in https://reviews.llvm.org/D92569. https://clang.llvm.org/docs/AutomaticReferenceCounting.html#arc-runtime-objc-autoreleasereturnvalue What this patch does to fix the problem: - The front-end adds operand bundle "clang.arc.attachedcall" to calls, which indicates the call is implicitly followed by a marker instruction and an implicit retainRV/claimRV call that consumes the call result. In addition, it emits a call to @llvm.objc.clang.arc.noop.use, which consumes the call result, to prevent the middle-end passes from changing the return type of the called function. This is currently done only when the target is arm64 and the optimization level is higher than -O0. - ARC optimizer temporarily emits retainRV/claimRV calls after the calls with the operand bundle in the IR and removes the inserted calls after processing the function. - ARC contract pass emits retainRV/claimRV calls after the call with the operand bundle. It doesn't remove the operand bundle on the call since the backend needs it to emit the marker instruction. The retainRV and claimRV calls are emitted late in the pipeline to prevent optimization passes from transforming the IR in a way that makes it harder for the ARC middle-end passes to figure out the def-use relationship between the call and the retainRV/claimRV calls (which is the cause of PR31925). - The function inliner removes an autoreleaseRV call in the callee if nothing in the callee prevents it from being paired up with the retainRV/claimRV call in the caller. It then inserts a release call if claimRV is attached to the call since autoreleaseRV+claimRV is equivalent to a release. If it cannot find an autoreleaseRV call, it tries to transfer the operand bundle to a function call in the callee. This is important since the ARC optimizer can remove the autoreleaseRV returning the callee result, which makes it impossible to pair it up with the retainRV/claimRV call in the caller. If that fails, it simply emits a retain call in the IR if retainRV is attached to the call and does nothing if claimRV is attached to it. - SCCP refrains from replacing the return value of a call with a constant value if the call has the operand bundle. This ensures the call always has at least one user (the call to @llvm.objc.clang.arc.noop.use). - This patch also fixes a bug in replaceUsesOfNonProtoConstant where multiple operand bundles of the same kind were being added to a call. Future work: - Use the operand bundle on x86-64. - Fix the auto upgrader to convert call+retainRV/claimRV pairs into calls with the operand bundles. rdar://71443534 Differential Revision: https://reviews.llvm.org/D92808
…rary This patch adds a pass to replace calls to vector intrinsics (i.e., LLVM intrinsics operating on vector operands) with calls to a vector library. Currently, calls to LLVM intrinsics are only replaced with calls to vector libraries when scalar calls to intrinsics are vectorized by the Loop- or SLP-Vectorizer. With this pass, it is now possible to replace calls to LLVM intrinsics already operating on vector operands, e.g., if such code was generated by MLIR. For the replacement, information from the TargetLibraryInfo, e.g., as specified via -vector-library is used. This is a re-try of the original commit 2303e93 that was reverted due to pass manager problems. Other minor changes have also been made. Differential Revision: https://reviews.llvm.org/D95373
These two instructions are VOP3P and have op_sel_hi bits, however do not use op_sel_hi. That is recommended to set unused op_sel_hi bits to 1. However, we cannot decode both representations with 1 and 0 if bits are set to default value 1. If bits are set to be ignored with '?' initializer then encoding defaults them to 0. The patch is a hack to force ignored '?' bits to 1 on encoding for these instructions. There is still canonicalization happens on disasm print if incoming values are non-default, so that disasm output does not match binary input, but this is pre-existing problem for all instructions with '?' bits. Fixes: SWDEV-272540 Differential Revision: https://reviews.llvm.org/D96543
This allows for suspend point specific resume function types. Return values from a suspend point can therefore be modelled as arguments to the resume function. Allowing for directly passed return types. Differential Revision: https://reviews.llvm.org/D96136
It was added by D96160, will be used by D96564. Some OS got errors if it is not used. Comment it out for the time being.
This reverts commit 973e133. It triggers an issue in gcc5 that require investigation, the build is broken with: /tmp/ccdpj3B9.s: Assembler messages: /tmp/ccdpj3B9.s:5821: Error: symbol `_ZNSt17_Function_handlerIFvjjEUljjE2_E9_M_invokeERKSt9_Any_dataOjS6_' is already defined /tmp/ccdpj3B9.s:5860: Error: symbol `_ZNSt14_Function_base13_Base_managerIUljjE2_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation' is already defined
class types. The goal is to provide a way to bypass constructor homing when emitting class definitions and force class definitions in the debug info. Not sure about the wording of the attribute, or whether it should be specific to classes with constructors
…dbots. Not sure what the issue is, but it might be because the test copies llvm-symbolizer to a different directory, and it can't find libc++. Try to add some REQUIRES that we use in other tests where we copy llvm tools out of their original directories.
… for" Didn't mean to commit this. This reverts commit 1b5c291.
Begin transitioning the X86 vector code to recognise sub(umax(a,b) ,b) or sub(a,umin(a,b)) USUBSAT patterns to make it more generic and available to all targets. This initial patch just moves the basic umin/umax patterns to DAG, removing some vector-only checks on the way - these are some of the patterns that the legalizer will try to expand back to so we can be reasonably relaxed about matching these pre-legalization. We can handle the trunc(sub(..))) variants as well, which helps with patterns where we were promoting to a wider type to detect overflow/saturation. The remaining x86 code requires some cleanup first - some of it isn't actually tested etc. I also need to resurrect D25987. Differential Revision: https://reviews.llvm.org/D96413
This patch intended to provide additional interface to LLVMsymbolizer such that they work directly on object files. There is an existing method - symbolizecode which takes an object file, this patch provides similar overloads for symbolizeInlinedCode, symbolizeData, symbolizeFrame. This can be useful for clients who already have a in-memory object files to symbolize for. Patch By: pvellien (praveen velliengiri) Reviewed By: scott.linder Differential Revision: https://reviews.llvm.org/D95232
…ble. Given a floating point store from an extracted vector, with an integer VGETLANE that already exists, storing the existing VGETLANEu directly can be better for performance. As the value is known to already be in an integer registers, this can help reduce fp register pressure, removed the need for the fp extract and allows use of more integer post-inc stores not available with vstr. This can be a bit narrow in scope, but helps with certain biquad kernels that store shuffled vector elements. Differential Revision: https://reviews.llvm.org/D96159
We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting. On z/OS the lack of 'clock_gettime()' and 'time_point()' force us to look for alternatives. The current proposal is to use `gettimeofday()` for CLOCK_MONOTONIC which is also used in CLOCK_REALTIME. This will allow us to skip the assertion with compromised CLOCK_MONOTONIC implementation which will not guarantee to never go back in time because it will use `gettimeofday()` but only when it's set. Is this a good compromise for platforms which does not support monotonic clock? Hopefully this will spark the discussion and agreement how to proceed in this situation. Reviewed By: #libc, ldionne, hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D93542
The error message should be about coro.id, not coro.begin Differential Revision: https://reviews.llvm.org/D96447
Some of these accidentally disabled tests failed as a result; updated tests per @qcolombet instructions. A small number needed additional updates because legalization has actually changed since they were written. Found by the Rotten Green Tests project. Differential Revision: https://reviews.llvm.org/D95257
This patch adds the 'vector.load' and 'vector.store' ops to the Vector dialect [1]. These operations model *contiguous* vector loads and stores from/to memory. Their semantics are similar to the 'affine.vector_load' and 'affine.vector_store' counterparts but without the affine constraints. The most relevant feature is that these new vector operations may perform a vector load/store on memrefs with a non-vector element type, unlike 'std.load' and 'std.store' ops. This opens the representation to model more generic vector load/store scenarios: unaligned vector loads/stores, perform scalar and vector memory access on the same memref, decouple memory allocation constraints from memory accesses, etc [1]. These operations will also facilitate the progressive lowering of both Affine vector loads/stores and Vector transfer reads/writes for those that read/write contiguous slices from/to memory. In particular, this patch adds the 'vector.load' and 'vector.store' ops to the Vector dialect, implements their lowering to the LLVM dialect, and changes the lowering of 'affine.vector_load' and 'affine.vector_store' ops to the new vector ops. The lowering of Vector transfer reads/writes will be implemented in the future, probably as an independent pass. The API of 'vector.maskedload' and 'vector.maskedstore' has also been changed slightly to align it with the transfer read/write ops and the vector new ops. This will improve reusability among all these operations. For example, the lowering of 'vector.load', 'vector.store', 'vector.maskedload' and 'vector.maskedstore' to the LLVM dialect is implemented with a single template conversion pattern. [1] https://llvm.discourse.group/t/memref-type-and-data-layout/ Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96185
Align the vector gather/scatter/expand/compress API with the vector load/store/maskedload/maskedstore API. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D96396
…ation after D95916 Their names don't convey much information, so they should be excluded. The behavior matches addr2line. Differential Revision: https://reviews.llvm.org/D96617
It looks like a previous change switched these from LLDB_LOGF but did not update the format strings. Differential Revision: https://reviews.llvm.org/D96550
This revision takes advantage of the newly extended `ref` directive in assembly format to allow better region handling for LinalgOps. Specifically, FillOp and CopyOp now build their regions explicitly which allows retiring older behavior that relied on specific op knowledge in both lowering to loops and vectorization. This reverts commit 3f22547 and reland 973e133 with a workaround for a gcc bug that does not accept lambda default parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59949 Differential Revision: https://reviews.llvm.org/D96598
This change adds additional unit tests for fuzzer::Merger::Parse and fuzzer::Merger::Merge in anticipation of additional changes to the merge control file format to support cross-process fuzzing. It modifies the parameter handling of Merge slightly in order to make NewFeatures and NewCov consistent with NewFiles; namely, Merge *replaces* the contents of these output parameters rather than accumulating them (thereby fixing a buggy return value). This is change 1 of (at least) 18 for cross-process fuzzing support. Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D94506
Temporary disable this extension until some targets support it.
This also reverts commit 59ecd8783b36e1ba2b42e020d46456329554f107, which is directly related to default pass manager type.
vmaksimo
changed the title
|
/summary:run |
|
/summary:run |
vmaksimo
changed the title
vmaksimo
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
DenisBakhvalov,
elizabethandrews,
kbobrovs,
mdtoguchi and
premanandrao
as code owners
This was referenced Mar 3, 2021
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@715dc55
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@b89b25f