-
Notifications
You must be signed in to change notification settings - Fork 788
LLVM and SPIRV-LLVM-Translator pulldown (WW44) #7186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Removing volatile may help optimization passes do more to the IR. However, this will increase scheduler freedom.
Make load and store non-atomic. Make the others monotonic. We could probably try to incrementally relax the orderings; not sure how useful that would be.
This was making decisions based on BBsToDelete, while being used to determine BBsToDelete which doesn't really work. Additionally, this is a lot of logic just to avoid deleting the entry block when we can just skip it.
emitCallAndSwitchStatement creates placeholder allocas to pass to these, so the types need to match.
Use 'm68k' (i.e. m68k-unknown-unknown) in all codegen tests rather than m68k-linux-gnu. NFC.
ce3c3cb broke this by speculatively making transforms before checking shouldKeep. Originally I tried to roll back changes to the IR, but it's probably best to not touch it before querying.
Copy this technique from bugpoint. Before trying to blindly delete blocks, try to fold branch conditions. This intuitively makes more sense for a faster reduction, since you can find dead paths in the function to prune out before trying to bisect blocks in source order. Seems to provide some speedup on my multi-hour reduction samples. This does have the potential to produce testcases with unreachable blocks. This is already a problem with the existing block reduction pass. I'm struggling dealing with invalid reductions in these cases, so in the future this should probably start deleting those. However, I do sometimes try to reduce failures in code that becomes unreachable, so I'm not totally sure what to do here.
The time profiler in `Expr::isIntegerConstantExpr` used to call `Loc->printToString`, it was inconsistent with other time profiles in the file and caused segfaults if `Loc` was `nullptr`. Fixes llvm/llvm-project#58551 Reviewed By: dyung, jloser Differential Revision: https://reviews.llvm.org/D136549
Add the atomic subroutines, atomic_define and atomic_ref, to the list of intrinsic subroutines. Add a new function CheckAtomicDefineAndRef to check that for each of these procedures, that their value arguments are the same type as their atom arguments, and that their 3rd argument is not coindexed. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D136206
CONFLICT (content): Merge conflict in llvm/test/Transforms/Util/add-TLI-mappings.ll
LINK/UNLNK have been implemented in 64d326c.
Introduce LLVM_LIT_ARGS cache variable in standalone builds, to let the caller override the options passed by LLVM to lit calls. Once defined, this is automatically handled by LLVM's cmake logic. Differential Revision: https://reviews.llvm.org/D136556
llvm-debuginfo-analyzer is a command line tool that processes debug info contained in a binary file and produces a debug information format agnostic “Logical View”, which is a high-level semantic representation of the debug info, independent of the low-level format. The code has been divided into the following patches: 1) Interval tree 2) Driver and documentation 3) Logical elements 4) Locations and ranges 5) Select elements 6) Warning and internal options 7) Compare elements 8) ELF Reader 9) CodeView Reader Full details: https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570 This patch: Warning and internal options - Support for '--warning' options. - Support for '--internal' options. Reviewed By: psamolysov, probinson Differential Revision: https://reviews.llvm.org/D125781
The 'clang-ppc64le-linux-multistage24452' buildbot fails with: https://lab.llvm.org/buildbot#builders/121/builds/24452 undefined reference to `llvm::dwarf::TagString(unsigned int)' Add 'DebugInfoDWARF' in the CMakeLists.txt CMake file.
Clang is generating different mangled names for the same lambda function in slightly changed builds (like with non-related source/Macro change). This is due to the fact that clang uses a cross-translation-unit sequential string "$_<n>" in lambda's mangled name. Here, "n" is the AnonStructIds field in MangleContext. Different mangled names for a unchanged function is undesirable: it makes perf comparison harder, and can cause some unnecessary profile mismatch in SampleFDO. This patch makes mangled name for lambda functions more stable by changing AnonStructIds to a per-function based seq number if the DeclContext is a function. Differential Revision: https://reviews.llvm.org/D136397
This patch fixes: mlir/include/mlir/IR/PatternMatch.h:1092:63: warning: parameter ‘values’ set but not used [-Wunused-but-set-parameter]
Switch to autogenerated tests so we can use the same test for GISel and DAGIsel. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D136446
This patch adds AArch64 to the LP64 feature to avoid running LLP64 incompatible test on AArch64/Windows platform. Differential Revision: https://reviews.llvm.org/D136070
…ments Tests that `CPlusPlusLanguage::MethodName` can parse demangled names that contain references to C-arrays. Example taken from libcxx API in the wild.
We currently wrap all multi-bit cases with a string, but this is overly restrictive. This commit refactors to use keywords when we know they are valid, and only degrade to string when the validity of the bitgroup is unknown. Differential Revision: https://reviews.llvm.org/D136540
We currently only support one level of aliases, which isn't great in situations where an attribute/type can have multiple duplicated components nested within it(e.g. debuginfo metadata). This commit refactors alias generation to support nested aliases, which requires changing alias grouping to take into account the depth of child aliases, to ensure that attributes/types aren't printed before the aliases they use. The only real user facing change here was that we no longer print 0 as an alias suffix, which would be unnecessarily expensive to keep in the new alias generation method (and isn't that valuable of a behavior to preserve). Differential Revision: https://reviews.llvm.org/D136541
This adds a subset of the necessary metadata for defining debug info in the LLVM dialect. It doesn't import everything, but just enough to start actually generating LLVM debug info the expected way. Export/Import to LLVMIR will be added in a followup. Differential Revision: https://reviews.llvm.org/D136542
Just look into several lit. 64 SPIRV lit failed on ubuntu2004_opaque_pointers_build_test since the lit are using old pointer type. |
I think opaque pointers task issues could be ignored at this point. Adding @bader to comment. |
Adding @jcranmer-intel for his comments. Thanks |
@preethi-intel, please, make sure that PR does not introduce new failures to existing jobs. You can find the results to compare with in Actions tab. Here is the link to the latest nightly - https://github.com/intel/llvm/actions/runs/3334289832/jobs/5517090344. |
From what I see, the new llvm-spirv lit test failures in opaque mode are transcoding/multiple_user_semantic{,_nopaque}.ll, which were newly added in the pulldown, so it's not causing any regressions to llvm-spirv tests. |
I'm referring to |
@bader We have opened internal tracker for the team to look into these check-clang fails. |
9d46e45
to
9c04baa
Compare
…in.h, NFCI Co-authored-by: Mariya Podchishchaeva <[email protected]>
9c04baa
to
0937ec5
Compare
Turns out the test tested buggy behaviour that was fixed by https://reviews.llvm.org/D134813 .
Disable printing anonymous tag locations because Windows file path separators are treated as escape sequences and cause errors when integration header is compiled with host compiler.
…ifier initializeOutputBuffer * [demangler] Simplify OutputBuffer initialization Every non-testcase use of OutputBuffer contains code to allocate an initial buffer (using either 128 or 1024 as initial guesses). There's now no need to do that, given recent changes to the buffer extension heuristics -- it allocates a 1k(ish) buffer on first need. Just pass in a buffer (if any) to the constructor. Thus the OutputBuffer's ownership of the buffer starts at its own lifetime start. We can reduce the lifetime of this object in several cases. That new constructor takes a 'size_t *' for the size argument, as all uses with a non-null buffer are passing through a malloc'd buffer from their own caller in this manner. The buffer reset member function is never used, and is deleted. Some adjustment to a couple of uses is needed, due to the lazy buffer creation of this patch. a) the Microsoft demangler can demangle empty strings to nothing, which it then memoizes. We need to avoid the UB of passing nullptr to memcpy. b) a unit test checks insertion of no characters into an empty buffer. We need to avoid UB when converting that to std::string. The original buffer initialization code would return a failure code if that first malloc failed. Existing code either ignored that, called std::terminate with a FIXME, or returned an error code. But that's not foolproof anyway, as a subsequent buffer extension failure ends up calling std::terminate. I am working on addressing that unfortunate failure mode in a manner more consistent with the C++ ABI design. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D122604 Co-authored-by: Nathan Sidwell <[email protected]>
… D. (2) Added -opaque-pointers option to LTO LIT tests
0937ec5
to
79509df
Compare
// host code is compiled with device compiler for SPIR target. | ||
// FIXME: device code specific diagnostic is probably needed. | ||
if (!(!TypeSize && | ||
(getLangOpts().OpenMPIsDevice || getLangOpts().SYCLIsDevice))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you double check if OpenMPIsDevice
switch is required here? It may not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@preethi-intel, have you open a ticket for this FIXME to follow up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pvchupin , I have opened an internal tracker for this FIXME. Not for the comment though.
// host code is compiled with device compiler for SPIR target. | ||
// FIXME: device code specific diagnostic is probably needed. | ||
if (!S.Context.getTargetInfo().hasBFloat16Type() && | ||
!S.getLangOpts().SYCLIsDevice && !S.getLangOpts().OpenMPIsDevice) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here of course.
/merge |
Mon 31 Oct 2022 07:34:54 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes. |
Mon 31 Oct 2022 07:44:18 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later. |
This PR is intended to fix matrix test failures caused by upcoming pulldown: #7186
LLVM: llvm/llvm-project@cb088e8
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@7a559fa