Skip to content

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

Merged
merged 2,189 commits into from
Oct 31, 2022

Conversation

preethi-intel
Copy link
Contributor

arsenm and others added 30 commits October 23, 2022 15:16
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
@haonanya haonanya requested a review from mdtoguchi October 26, 2022 05:36
@haonanya
Copy link
Contributor

Just look into several lit. 64 SPIRV lit failed on ubuntu2004_opaque_pointers_build_test since the lit are using old pointer type.

@pvchupin
Copy link
Contributor

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.

@asudarsa
Copy link
Contributor

Adding @jcranmer-intel for his comments. Thanks

@bader
Copy link
Contributor

bader commented Oct 27, 2022

@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.
I see that this PR introduces regressions to post-commit and nightly builds.

@jcranmer-intel
Copy link
Contributor

@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. I see that this PR introduces regressions to post-commit and nightly builds.

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.

@bader
Copy link
Contributor

bader commented Oct 27, 2022

I see that this PR introduces regressions to post-commit and nightly builds.

I'm referring to check-clang failures here.

@preethi-intel
Copy link
Contributor Author

preethi-intel commented Oct 27, 2022

I see that this PR introduces regressions to post-commit and nightly builds.

I'm referring to check-clang failures here.

@bader We have opened internal tracker for the team to look into these check-clang fails.

@preethi-intel preethi-intel force-pushed the llvmspirv_pulldown_w44 branch from 9c04baa to 0937ec5 Compare October 30, 2022 21:32
Fznamznon and others added 9 commits October 30, 2022 14:42
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
@preethi-intel preethi-intel force-pushed the llvmspirv_pulldown_w44 branch from 0937ec5 to 79509df Compare October 30, 2022 21:44
// host code is compiled with device compiler for SPIR target.
// FIXME: device code specific diagnostic is probably needed.
if (!(!TypeSize &&
(getLangOpts().OpenMPIsDevice || getLangOpts().SYCLIsDevice))) {
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

@Fznamznon Fznamznon Oct 31, 2022

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here of course.

@pvchupin
Copy link
Contributor

/merge

@bb-sycl
Copy link
Contributor

bb-sycl commented Oct 31, 2022

Mon 31 Oct 2022 07:34:54 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes.

@bb-sycl
Copy link
Contributor

bb-sycl commented Oct 31, 2022

Mon 31 Oct 2022 07:44:18 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later.

@bb-sycl bb-sycl merged commit 2ba28e8 into intel:sycl Oct 31, 2022
againull added a commit that referenced this pull request Nov 2, 2022
This PR is intended to fix matrix test failures caused by upcoming
pulldown: #7186
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disable-lint Skip linter check step and proceed with build jobs
Projects
None yet
Development

Successfully merging this pull request may close these issues.