LLVM and SPIRV-LLVM-Translator pulldown (WW36) #2390
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
Quiet mode is very useful for scripting, when only the diff format output is required, or no output if not formatting is needed. In case of no modified files, git-clang-format will output to screen even though the quiet mode enabled. This patch changes this behavior, so if quiet flag passes in - no output will be available, even if no modified files exists. Differential Revision: https://reviews.llvm.org/D85485
Asan has picked up a memory leak, which will require some investigation: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/45372/steps/check-llvm%20asan/logs/stdio This reverts commit 60db26a.
…ies don't exist Currently, libFuzzer will exit with an error message if a non-existent corpus directory is provided. However, if a user provides a non-existent directory for the `artifact_prefix`, `exact_artifact_path`, or `features_dir`, libFuzzer will continue execution but silently fail to write artifacts/features. To improve the user experience, this PR adds validation for the existence of all user supplied directories before executing the main fuzzing loop. If they don't exist, libFuzzer will exit with an error message. Patch By: dgg5503 Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D84808
The non-standard header file `<sysexits.h>` provides some return values. `EX_IOERR` is used to as a special value to signal a broken pipe to the clang driver. On z/OS Unix System Services, this header file does not exists. This patch - adds a check for `<sysexits.h>`, removing the dependency on `LLVM_ON_UNIX` - adds a new header file `llvm/Support/ExitCodes`, which either includes `<sysexits.h>` or defines `EX_IOERR` - updates the users of `EX_IOERR` to include the new header file Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D83472
Fix: Add missing `List::getTerminationKind()`, `List::canBeEmpty()`, `List::getDelimiterTokenKind()` for `CallArguments`. Differential Revision: https://reviews.llvm.org/D86600
This function seems to allow for the shift amount to have a different type than the result, but I don't think we do that anywhere else for vector shifts. We also don't have any support for legalizing the shift amount alone if the result is legal and the shift amount type isn't. The code coverage report here shows this code as uncovered http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp.html Differential Revision: https://reviews.llvm.org/D86475
Fixes a build failure in the Darwin kernel. Tested with: % nm -mU lib/libclang_rt.cc_kext_x86_64h_osx.a | grep __llvm_profile_raw_version rdar://67809173
Summary: Support TOCU and TOCL relocation type for object file generation. Reviewed by: DiggerLin Differential Revision: https://reviews.llvm.org/D84549
Instead of computing GUID based on some assumption about symbol mangling rule from IRName to symbol name, lookup the IRName from all the symtabs from all the input files to see if there are any matching symbols entry provides the IRName for GUID computation. rdar://65853754 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D84803
This intrinsic only accepted proper machine vector lengths. Fixed by this change. With unit tests. https://bugs.llvm.org/show_bug.cgi?id=47299 Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D86585
This broke stage2 of clang-cmake-aarch64-full. This reverts commit a0aed80.
…ultiple uses It is fine if the operation has multiple uses, as long as they are all in this very PHI node.
In those cases, it really means "N uses".
…transforms to be one-user checks As FIXME said, they really should be checking for a single user, not use, so let's do that. It is not *that* unusual to have the same value as incoming value in a PHI node, not unlike how a PHI may have the same incoming basic block more than once. There isn't a nice way to do that, Value::users() isn't uniqified, and Value only tracks it's uses, not Users, so the check is potentially costly since it does indeed potentially involes traversing the entire use list of a value.
This fixes a crash when declaring a destructor with a wrong name, then writing result to pch file and loading it again. The PCH storage uses DeclarationNameKey as key and it is the same key for both the invalid destructor and the implicit one that was created because the other one was invalid. When querying for the Foo::~Foo we end up getting Foo::~Bar, which is then rejected and we end up with nullptr in CXXRecordDecl::GetDestructor(). Fixes https://bugs.llvm.org/show_bug.cgi?id=47270 Differential Revision: https://reviews.llvm.org/D86624
…trol displacement size.
This is an older syntax than the {disp32} and {disp8} pseudo
prefixes that were added a few weeks ago. We can reuse most of
the support for that to support .d32 and .d8 as well.
This patch adds NoUndef to Intrinsics.td. The attribute is attached to llvm.assume's operand, because llvm.assume(undef) is UB. It is attached to pointer operands of several memory accessing intrinsics as well. This change makes ValueTracking::getGuaranteedNonPoisonOps' intrinsic check unnecessary, so it is removed. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D86576
…stance and indirect call promotion candidate. Profile remapping is a feature to match a function in the module with its profile in sample profile if the function name and the name in profile look different but are equivalent using given remapping rules. This is a useful feature to keep the performance stable by specifying some remapping rules when sampleFDO targets are going through some large scale function signature change. However, currently profile remapping support is only valid for outline function profile in SampleFDO. It cannot match a callee with an inline instance profile if they have different but equivalent names. We found that without the support for inline instance profile, remapping is less effective for some large scale change. To add that support, before any remapping lookup happens, all the names in the profile will be inserted into remapper and the Key to the name mapping will be recorded in a map called NameMap in the remapper. During name lookup, a Key will be returned for the given name and it will be used to extract an equivalent name in the profile from NameMap. So with the help of the NameMap, we can translate any given name to an equivalent name in the profile if it exists. Whenever we try to match a name in the module to a name in the profile, we will try the match with the original name first, and if it doesn't match, we will use the equivalent name got from remapper to try the match for another time. In this way, the patch can enhance the profile remapping support for searching inline instance and searching indirect call promotion candidate. In a planned large scale change of int64 type (long long) to int64_t (long), we found the performance of a google internal benchmark degraded by 2% if nothing was done. If existing profile remapping was enabled, the performance degradation dropped to 1.2%. If the profile remapping with the current patch was enabled, the performance degradation further dropped to 0.14% (Note the experiment was done before searching indirect call promotion candidate was added. We hope with the remapping support of searching indirect call promotion candidate, the degradation can drop to 0% in the end. It will be evaluated post commit). Differential Revision: https://reviews.llvm.org/D86332
This would assert with unaligned DS access enabled. The offset may not
be aligned. Theoretically the pattern predicate should check the
memory alignment, although it is possible to have the memory be
aligned but not the immediate offset.
In this case I would expect it to use ds_{read|write}_b64 with
unaligned access, but am not clear if there's a reason it doesn't.
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D82582
As suggested by David Blaike at https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200824/822584.html
As suggested by David Blaikie at ihttps://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200824/822584.html
For `ld64` which uses legacy LTOCodeGenerator, it relies on writeMergedModule to perform `ld -r` (generates a linked object file). If all the inputs to `ld -r` is fullLTO bitcode, `ld64` will linked the bitcode module, internalize all the symbols and write out another fullLTO bitcode object file. This bitcode file doesn't have all the bitcode inputs and it should not have LTOPostLink module flag. It will also cause error when this bitcode object file is linked with other LTO object file. Fix the issue by not applying LTOPostLink flag during writeMergedModule function. The flag should only be added when all the bitcode are linked and ready to be optimized. rdar://problem/58462798 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D84789
The version of `st1d` that operates with vector plus immediate
addressing mode uses the alias `st1d { <Zn>.d }, <Pg>, [<Za>.d]` for
rendering `st1d { <Zn>.d }, <Pg>, [<Za>.d, #0]`. The disassembler was
generating `<Zn>.s` instead of `<Zn>.d>`.
Differential Revision: https://reviews.llvm.org/D86633
InstSimplify should do all transformations that ConstProp does, but one thing that ConstProp does that InstSimplify wouldn't is inline vector instructions that are constants, e.g. into a ret. Previously vector instructions wouldn't be inlined in InstSimplify because llvm::Simplify*Instruction() would return nullptr for specific instructions, such as vector instructions that were actually constants, if it couldn't simplify them. This changes SimplifyInsertElementInst, SimplifyExtractElementInst, and SimplifyShuffleVectorInst to return a vector constant when possible. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D85946
it's being built and called (and substituted).
Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D86563
Patch by [email protected] Differential Revision: https://reviews.llvm.org/D86552
Put newly created insertElement instructions at the ends of the incoming blocks instead of putting them immediately before the phi thus breaking the module.
…adata.cpp SPIRV metadata contains pointers to relevant functions Passes like SPIRVLowerOCLBlocks and SPIRVRegularizeLLVM can erase declarations with no usage and invalidate those pointers
Ignore other than constant integer type instead of crashing. Signed-off-by: Dmitry Sidorov <[email protected]>
Fixed bug leaded to release build fail occured by Float Control decs commit
New option allows to specify which version of extended instruction set for representing debug info should be used
3.23 Loop Control: If there are multiple following operands indicated, they are ordered: Those indicated by smaller-numbered bits appear first. This rule was violated in previous implementation. Signed-off-by: Dmitry Sidorov <[email protected]>
vladimirlaz
requested review from
a team,
AGindinson,
AlexeySachkov,
AlexeySotkin,
Fznamznon,
bader,
elizabethandrews,
mdtoguchi and
premanandrao
as code owners
vladimirlaz
force-pushed
the
llvmspirv_pulldown
branch
from
2011b96 to
b74ec89
Compare
Contributor
Author
|
/summary:run |
Contributor
Author
|
/summary:run |
Chenyang-L
pushed a commit
that referenced
this pull request
Feb 18, 2025
add tests for low-power events extension
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
89 participants
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@3fe01f0
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@cdede2c