LLVM and SPIRV-LLVM-Translator pulldown (WW42) #2628
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
The sign of the scaling factor was misinterpreted for output as meaning what it does for input. To be correct, they should cancel each other out. print '(1P,F4.3)', 1. ! printed 0.1 but should print 10.0 Differential revision: https://reviews.llvm.org/D88610
…s which are only ever stored to always use a legal integer type if one is available." (PR47592) (it was introduced in https://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html) This canonicalization seems dubious. Most importantly, while it does not create `inttoptr` casts by itself, it may cause them to appear later, see e.g. D88788. I think it's pretty obvious that it is an undesirable outcome, by now we've established that seemingly no-op `inttoptr`/`ptrtoint` casts are not no-op, and are no longer eager to look past them. Which e.g. means that given ``` %a = load i32 %b = inttoptr %a %c = inttoptr %a ``` we likely won't be able to tell that `%b` and `%c` is the same thing. As we can see in D88789 / D88788 / D88806 / D75505, we can't really teach SCEV about this (not without the https://bugs.llvm.org/show_bug.cgi?id=47592 at least) And we can't recover the situation post-inlining in instcombine. So it really does look like this fold is actively breaking otherwise-good IR, in a way that is not recoverable. And that means, this fold isn't helpful in exposing the passes that are otherwise unaware of these patterns it produces. Thusly, i propose to simply not perform such a canonicalization. The original motivational RFC does not state what larger problem that canonicalization was trying to solve, so i'm not sure how this plays out in the larger picture. On vanilla llvm test-suite + RawSpeed, this results in increase of asm instructions and final object size by ~+0.05% decreases final count of bitcasts by -4.79% (-28990), ptrtoint casts by -15.41% (-3423), and of inttoptr casts by -25.59% (-6919, *sic*). Overall, there's -0.04% less IR blocks, -0.39% instructions. See https://bugs.llvm.org/show_bug.cgi?id=47592 Differential Revision: https://reviews.llvm.org/D88789
Adds support for SPIR-V composite speciailization constants to spv._reference_of. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D88732
This reverts commit 2079798. This patch (https://reviews.llvm.org/D69257) cannot complete a stage2 build due to the change: ``` CI->getCalledFunction()->getName().contains("longjmp") ``` There are several concrete issues here: - The callee may not be a function, so `getCalledFunction` can assert. - The called value may not have a name, so `getName` can assert. - There's no distinction made between "my_longjmp_test_helper" and the actual longjmp libcall. At a higher level, there's a serious layering problem here. The splitting pass makes policy decisions in a general way (e.g. based on attributes or profile data). Special-casing certain names breaks the layering. It subverts the work of library maintainers (who may now need to opt-out of unexpected optimization behavior for any affected functions) and can lead to inconsistent optimization behavior (as not all llvm passes special-case ".*longjmp.*" in the same way). The patch may need significant revision to address these issues. But the immediate issue is that this crashes while compiling llvm's unit tests in a stage2 build (due to the `getName` problem).
Patch by pi1024e (email unavailable) Differential Revision: https://reviews.llvm.org/D82593
…es FP constants to RHS. getNode handling for ISD:SETCC calls FoldSETCC which can canonicalize FP constants to the RHS. When this happens we should create the node with the FMF that was requested. By using FlagInserter when can ensure any calls to getNode/getSetcc during canonicalization will also get the flags. Differential Revision: https://reviews.llvm.org/D88063
…seudo instruction This and its friend X86ISD::LCMPXCHG8_SAVE_RBX_DAG are used if we need to avoid clobbering the frame pointer in EBX/RBX. EBX/RBX are only used a frame pointer in 64-bit mode. In 64-bit mode we don't use CMPXCHG8B since we have a GR64 cmpxchg available. So we don't need special handling for LCMPXCHG8B. Split from D88808 Differential Revision: https://reviews.llvm.org/D88853
This is flagged by PyCharm and can cause subtle bugs. While changing this also re-sort the imports and add missing ones. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D88816
The test disables suppression and therefore sometimes triggers a know false positive in the openmp runtime. The test should only verify that the env var is handles as expected.
Register context information was already being passed into the DWARFDebugFrame code that dumps unwind information but it wasn't being used. This change adds the ability to dump registers names of a valid MC register context was passed in and if it knows about the register. Updated the tests to use the newly returned register names. Differential Revision: https://reviews.llvm.org/D88767
This was looking at the privateState, but it's possible that the actual process has started up and then stopped again by the time we get to the check, which would lead us to get out of running the stop hooks too early. Instead we need to track the intention of the stop hooks directly. Differential Revision: https://reviews.llvm.org/D88753
Instead of using ad-hoc mechanisms to disable the tests in C++ < 14, use UNSUPPORTED markup.
This separates the two concerns - encapsulation of traversal order; and iteration. Differential Revision: https://reviews.llvm.org/D88256
Fix test for the SiFive E76 core. This patch fixes the issue introduced by the commit 5d6d8a2.
When unbundling COPY bundles in VirtRegRewriter the start of the bundle is not correctly referenced in the unbundling loop. The effect of this is that unbundled instructions are sometimes inserted out-of-order, particular in cases where multiple reordering have been applied to avoid clobbering dependencies. The resulting instruction sequence clobbers dependencies. Reviewed By: foad Differential Revision: https://reviews.llvm.org/D88821
Refactor exit block creation to a single call ensureEarlyExitBlock. Add support for generating an early exit block which clears the exec mask, but only add this instruction when required. These changes are to facilitate adding more forms of early termination for PS shaders in the near future. Reviewed By: nhaehnle Differential Revision: https://reviews.llvm.org/D88775
Factored out the logging facility, to allow its reuse outside the inliner. Differential Revision: https://reviews.llvm.org/D88770
This makes the NPM skip not required passes on functions marked optnone.
If this causes a pass that should be required but has not been marked
required to be skipped, add
`static bool isRequired() { return true; }`
to the pass class. AlwaysInlinerPass is an example.
clang/test/CodeGen/O0-no-skipped-passes.c is useful for checking that
no passes are skipped under -O0.
The -enable-npm-optnone option will be removed once this has been stable
for long enough without issues.
Reviewed By: ychen, asbirlea
Differential Revision: https://reviews.llvm.org/D87869
evaluation diagnostics.
Ensure that we evaluate assignment and compound-assignment right-to-left, and array subscripting left-to-right. Fixes PR47724.
Simplify the logic of parsing the lldb -P output to find the python path. This removes the special handling for the LLDB.framework case and instead of pattern matching known errors focus on finding a directory path that contains an __init__.py. Differential revision: https://reviews.llvm.org/D88840
…ove safety of speculation Use context to prove that load can be safely executed at a point where load is being hoisted. Postpone the decision about safety of speculative load execution till the moment we know where we hoist load and check safety at that context. Reviewers: nikic, fhahn, mkazantsev, lebedev.ri, efriedma, reames Reviewed By: reames, mkazantsev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D88725
Alignment attributes need to be dropped for non-pointer values. This also introduces a check into the verifier to ensure you don't use `align` on anything but a pointer. Test needed to be adjusted accordingly. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D87304
Drop `noundef` for return values that are replaced by void and make it illegal to put `noundef` on a void value. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D87306
This patch enables basic BSS section handling, and improves a couple of error messages in the ELF section parsing code. Patch by Christian Schafmeister. Thanks Christian! Differential Revision: https://reviews.llvm.org/D88867
This reverts commit 69acdfe. Need to investigate reported miscompiles.
…anges Hopefully the last of these, apologies for the noise.
…recovery. see the whole context in: https://reviews.llvm.org/D85025 Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D84226
Object of class `Command` contains various properties of a command to execute, but output file was missed from them. This change adds this property. It is required for reporting consumed time and memory implemented in D78903 and may be used in other cases too. Differential Revision: https://reviews.llvm.org/D78902
CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/Clang.cpp
The most notable change is that usages of `std::string` were replaced with `llvm::StringRef` to simplify code and probably speedup it a little bit.
* Add llvm.abs.i32 intrinsic translation Add translation of @llvm.abs.* to `s_abs` extended instruction. Signed-off-by: amochalo <[email protected]>
When IVDep is applied to a regular kernel-scope array/pointer variable, the GEP instructions that access this variable are marked with index group metadata. When IVDep is applied to a captured argument of a kernel, however, the pointer operand of index group-marked instructions becomes a GEP itself. The latter GEP accesses the closure of a kernel lambda with an offset that signifies the number of the captured parameter in the closure layout. To treat the second case: 1. In forward translation, we ensure that for each memory block, all pointer accesses marked into IVDep index groups are recognized and translated into LoopControl parameters. Previously, only the latest pointer access would get listed in the SPIR-V representation of attribute parameters. 2. In backward translation, we also differentiate between GEP instructions that access an array variable directly and the GEPs accessing the "closure field accesses". An additional map stores 1 index group metadata node per each "pointer to closure + integer offset" pair. This ensures that all accesses to the same kernel parameter are marked into the same index group on a given loop nest level. Signed-off-by: Artem Gindinson <[email protected]>
Add llvm.ctpop.* translation to BitCount instruction Add test for this Signed-off-by: amochalo <[email protected]>
* Add support for llvm.nearbyint.* intrinsic Signed-off-by: Aleksander Fadeev <[email protected]>
* Add ReadNone attr for Builtin functions Signed-off-by: Aleksander Fadeev <[email protected]>
Added following decoration and bidirectional translation it to "VCCallable" attribute
vmaksimo
requested review from
AGindinson,
AlexeySachkov,
AlexeySotkin,
bader,
elizabethandrews,
Fznamznon,
mdtoguchi and
premanandrao
as code owners
|
/summary:run |
Closed
"Funnel shift left" doesn't have an analogue in the OpenCL ExtInst set. We unroll `llvm.fshl.i<n>(i<n>, i<n>, i<n>)` into a small algorithm that performs the actual funnel shift. A detailed description of FSHL can be found at https://llvm.org/docs/LangRef.html#llvm-fshl-intrinsic Signed-off-by: Artem Gindinson <[email protected]>
|
/summary:run |
|
Merged. The failing tests are test issues (fixed/tested in intel/llvm-test-suite#39) |
kbenzie
pushed a commit
to kbenzie/intel-llvm
that referenced
this pull request
Feb 17, 2025
Remove unused `virtual` in cuda command buffers
Chenyang-L
pushed a commit
that referenced
this pull request
Feb 18, 2025
Remove unused `virtual` in cuda command buffers
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@70bf35070a74
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@c3c7e24