Skip to content

LLVM and SPIRV-LLVM-Translator pulldown (WW08 2024) #12799

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 722 commits into from
Feb 26, 2024
Merged

Conversation

sys-ce-bb
Copy link
Contributor

RoboTux and others added 30 commits February 20, 2024 09:54
…228)

Continuation of commit 42b5037, apply changes to the remaining
functions.
Code for function `fflush` was not changed, because it is more special
compared to the others.
We need to limit the shift width to the type bitwidth, then do the
shift and report success, but still diagnose what we limited the
shiftwidth.
…d_to_trunc (#82224)

This combine transforms an unmerge where only the first element is used
into a truncate. That works OK for scalar but for vector needs to insert
a bitcast to integers, perform the truncate then bitcast back to
vectors. This generates more awkward code than using an Unmerge.
If they aren't we need to load from the pointer the Store op
leaves on the stack.
…#82245)

Using OtherPredicates for True16 predicates is often problematic due to
interference with other kinds of predicates, particularly when this
overrides predicates inherited from pseudo instructions.
Extend the transform added in
llvm/llvm-project#76458 to also handle unsigned
division. X exact/ Y * Y == X holds independently of whether the
division is signed or unsigned.

Proofs: https://alive2.llvm.org/ce/z/wFd5Ec
AMDGPUDisassembler::getInstruction tries decoding instructions using
different DecoderTables in a confusing order: first 96-bit instructions,
then some 64-bit, then 32-bit, then some more 64-bit.

This patch changes it to always try longer encodings first. The
motivation is to make getInstruction easier to understand, and to pave
the way for combining some 64-bit tables that do not need to be
separate.
…#82011)"

This reverts commit 0e6a48c.

Temporary revert as it causes bad codegen: llvm/llvm-project#82011 (comment)
Remove the `-freroll-loops` flag, which has not had any effect since the
migration to the new pass manager. The underlying pass has been removed
entirely in #80972 due to lack of maintenance and known bugs.

Fixes llvm/llvm-project#59065.
This patch implements `__is_layout_compatible` intrinsic, which supports
`std::is_layout_compatible` type trait introduced in C++20
([P0466R5](https://wg21.link/p0466r5) "Layout-compatibility and
Pointer-interconvertibility Traits"). Name matches GCC and MSVC
intrinsic.

Basically, this patch exposes our existing machinery for checking for
layout compatibility and figuring out common initial sequences. Said
machinery is a bit outdated, as it doesn't implement
[CWG1719](https://cplusplus.github.io/CWG/issues/1719.html) "Layout
compatibility and cv-qualification revisited" and
[CWG2759](https://cplusplus.github.io/CWG/issues/2759.html)
"`[[no_unique_address]` and common initial sequence". Those defect
reports are considered out of scope of of this PR, but will be
implemented in subsequent PRs.

Partially addresses #48204
64-bit SDWA encodings have to be checked first because their first 32
bits are a special case of the corresponding 32-bit non-SDWA encoding of
the same instruction. But all 64-bit encodings are checked first, so we
don't need special handling for SDWA.
As part of the renaming the Standard dialect to Func dialect, *support*
for the `func.constant` operation was added to the emitter. However, the
emitter cannot emit function types. Hence the emission for a snippet
like

```
%0 = func.constant @myFN : (f32) -> f32

func.func private @myFN(%arg0: f32) -> f32 {
  return %arg0 : f32
}
```

failes with `func.mlir:1:6: error: cannot emit type '(f32) -> f32'`.
This removes `func.constant` from the emitter.
There used to be some diagnostic differences between the new
interpreter and the old one.
…82352)

widenIVUse may hoist a wide induction increment and introduce new uses,
but does not recompute the wrap flags. In some cases this can make the
new uses of the wide IV inc more poisonous.

Update the code to recompute flags if needed when hoisting an IV. If
both the narrow and wide IV increment's flags match and we can re-use
the flags from the increments, there's no need to recompute the flags,
as the replacement won't make the new uses of the wide IV's increment
more poisonous.

Note that this also updates a stale comment which claimed that the widen
increment is only used if it dominates the new use.

The helper should also be used to guard the code added in da43733,
which I am planning on doing separately once the helper lands.

Fixes llvm/llvm-project#82243.
…sts (#12760)

The test fails due missing warning, the warning was added in SYCL web
long time ago, vs e4f5d55

The test is newly added test from change:
5c57fd7

Co-authored-by: Jennifer Yu <jennifer.yu@intel.com>
This adds predefined formatting macros in C23 mode for printing unsigned
integers in binary format (e.g, UINT_FAST64_FMTB). These are used to
implement the PRIb (et al) macros in inttypes.h

Fixes llvm/llvm-project#81896

(Was previously reviewed in
[82037](llvm/llvm-project#82037), this is fixing
some failures found post-commit.)
This unrolls n-D vector.interleave ops like:

```mlir
vector.interleave %i, %j : vector<6x3xf32>
```

To a sequence of 1-D operations:
```mlir
%i_0 = vector.extract %i[0] 
%j_0 = vector.extract %j[0] 
%res_0 = vector.interleave %i_0, %j_0 : vector<3xf32>
vector.insert %res_0, %result[0] :
// ... repeated x6
```

The 1-D operations can then be directly lowered to LLVM.

Depends on: #80966
The section headers for XCOFF files have a subtype flag for Dwarf
sections. This PR updates obj2yaml, yaml2obj, and llvm-readobj so that
they recognize the subtype.
This patch removes the `-reverse-csr-restore-seq` option from
AArch64FrameLowering, since this is no longer used.
This patch extends [D36234](https://reviews.llvm.org/D36234) to handle
`zext nneg` instructions.
I found this while adding support for cast instructions in
`getFreelyInvertedImpl`.
Currently there are two versions of llvm::unique, one that requires a
predicate, and is in STLExtras.h; and one that does not require a
predicate, and is in GenericUniformityImpl.h. This moves the one from
GenericUniformityImp.h to STlExtras.h, so they are both together, and
can both be easily called from other places inside LLVM.
…(#81821)

IV variable are privatized during acc loop lowering. An hlfir.declare
operation is added when mapping the symbol to the new private value. In
order to avoid using multiple value in the acc.loop region, we map the
symbol to the result of the hlfir.declare operation inserted.
@jsji jsji marked this pull request as ready for review February 24, 2024 15:16
@jsji jsji requested review from a team and bader as code owners February 24, 2024 15:17
@jsji
Copy link
Contributor

jsji commented Feb 24, 2024

This is ready for review.

  • Enable support of non-instrinsic debug-info This is to reenable the support that we disabled in last week's pulldown after fixes in spirv translator and sycl-fusion (and community fixes). We are in sync with community now. @MrSidims @intel/dpcpp-tools-reviewers

@jsji
Copy link
Contributor

jsji commented Feb 24, 2024

Windows failure also seen in other PR. eg: https://github.com/intel/llvm/actions/runs/8029097434/job/21935148053

@jsji jsji self-assigned this Feb 24, 2024
@jsji
Copy link
Contributor

jsji commented Feb 26, 2024

@MrSidims @intel/dpcpp-tools-reviewers would you please add explicit comments/approval for Enable support of non-instrinsic debug-info so that this can be merged? Thanks!

@AlexeySachkov
Copy link
Contributor

@MrSidims @intel/dpcpp-tools-reviewers would you please add explicit comments/approval for Enable support of non-instrinsic debug-info so that this can be merged? Thanks!

Mechanical nature of the change looks good to me. Whether or not the rest of the stack is ready for this, I think @MrSidims should know better

@jsji
Copy link
Contributor

jsji commented Feb 26, 2024

Thanks @AlexeySachkov ! @MrSidims approved my draft PR to enable it here. #12768 (review).

The Pre-commit CI are happy with this, so I'd like to at least give it a try. We can always flip back if we find problems after turning it on (community has turned it on for weeks).

@jsji
Copy link
Contributor

jsji commented Feb 26, 2024

@bader @intel/llvm-gatekeepers OK to merge? Thanks.

@bader
Copy link
Contributor

bader commented Feb 26, 2024

/merge

@bb-sycl
Copy link
Contributor

bb-sycl commented Feb 26, 2024

Mon 26 Feb 2024 07:55:37 PM UTC --- Start to merge the commit into sycl branch. It will take several minutes.

@bb-sycl
Copy link
Contributor

bb-sycl commented Feb 26, 2024

Mon 26 Feb 2024 08:03:13 PM UTC --- Merge the branch in this PR to base automatically. Will close the PR later.

@bb-sycl bb-sycl merged commit ff16348 into sycl Feb 26, 2024
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.