[llvm-branch-commits] [llvm] release/18.x: github-upload-release.py: Fix bug preventing release creation (#84571) (PR #88425)

[Aiden Grossman via llvm-branch-commits]

https://github.com/boomanaiden154 approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/88425
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [mlir] Add dpas and named barrier ops (PR #88439)

[Adam Siemieniuk via llvm-branch-commits]

@@ -662,4 +662,152 @@ def XeGPU_UpdateOffsetOp: XeGPU_Op<"update_offset",
   }];
 }
 
+def XeGPU_DpasOp : XeGPU_Op<"dpas", [Pure, AllElementTypesMatch<["lhs", 
"rhs"]>]> {
+  let summary = "It performs mma computation";
+
+  let description = [{DPAS performs matrix multiplication on matrix A of `mxk`
+size, B of `kxn` size, and accumulate on matrix C of `mxn` to the same size
+matrix , `m=8`, `n=16` and `k=8 * 32/bit_width_of_elem_type`. So for fp16
+data type, the matrices are `A: vector<8x16xf16>`, `B: vector<16x16xf16>`,
+and `C/D: vector<8x16xf32>`. Besides the matrix size requirements, DPAS
+also requires A and B to be loaded with the required data layout. 
Specially,
+VNNI layout is required for B operand. It is achieved via setting 
`vnni_axis = 0`
+of the corresponding `load_nd` operator. To keep both operands as 3D 
vector,
+operand A is loaded via setting `vnni_axis = 1` without impacting the
+physical layouts change in register. Due to the VNNI transformation, A and 
B operands
+are represented as 3D vector, with the last dimension representing the 
VNNI factor,
+which is computed as `32/bit_width_of_elem_type`. Therefore, `A: 
vector<8x16xf16>`
+is represented as `A: vector<4x8x2xf16>`, and `B:vector<16x16xf16>` is
+represented as `B: vector<8x16x2xf16>`.
+
+Note: on PVC, the hardware can perform load with VNN transformation when 
data

adam-smnk wrote:

```suggestion
Note: on PVC, the hardware can perform load with VNNI transformation when 
data
```

https://github.com/llvm/llvm-project/pull/88439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [mlir] Add dpas and named barrier ops (PR #88439)

[Adam Siemieniuk via llvm-branch-commits]

@@ -662,4 +662,152 @@ def XeGPU_UpdateOffsetOp: XeGPU_Op<"update_offset",
   }];
 }
 
+def XeGPU_DpasOp : XeGPU_Op<"dpas", [Pure, AllElementTypesMatch<["lhs", 
"rhs"]>]> {
+  let summary = "It performs mma computation";
+
+  let description = [{DPAS performs matrix multiplication on matrix A of `mxk`
+size, B of `kxn` size, and accumulate on matrix C of `mxn` to the same size
+matrix , `m=8`, `n=16` and `k=8 * 32/bit_width_of_elem_type`. So for fp16
+data type, the matrices are `A: vector<8x16xf16>`, `B: vector<16x16xf16>`,
+and `C/D: vector<8x16xf32>`. Besides the matrix size requirements, DPAS
+also requires A and B to be loaded with the required data layout. 
Specially,
+VNNI layout is required for B operand. It is achieved via setting 
`vnni_axis = 0`
+of the corresponding `load_nd` operator. To keep both operands as 3D 
vector,
+operand A is loaded via setting `vnni_axis = 1` without impacting the
+physical layouts change in register. Due to the VNNI transformation, A and 
B operands
+are represented as 3D vector, with the last dimension representing the 
VNNI factor,
+which is computed as `32/bit_width_of_elem_type`. Therefore, `A: 
vector<8x16xf16>`
+is represented as `A: vector<4x8x2xf16>`, and `B:vector<16x16xf16>` is
+represented as `B: vector<8x16x2xf16>`.
+
+Note: on PVC, the hardware can perform load with VNN transformation when 
data
+  element type is 16-bit or lower precision, taking 2 or 4 elements 
from
+  the first dimension and inserted into the newly added innermost 
dimension.
+  }];
+
+  let arguments = (ins
+XeGPU_DpasOpType : $lhs,
+XeGPU_DpasOpType : $rhs,
+Optional: $acc);
+  let results = (outs XeGPU_Vector2DType: $result);
+
+  let extraClassDeclaration = [{
+VectorType getLhsType() {
+  return getLhs().getType();
+}
+
+VectorType getRhsType() {
+  return getRhs().getType();
+}
+
+VectorType getAccType() {
+  if (getAcc())
+return getAcc().getType();
+  return {};
+}
+
+VectorType getResultType() {
+  return getResult().getType();
+}
+  }];
+
+  let assemblyFormat = [{
+$lhs `,` $rhs (`,` $acc^)? attr-dict `:` type($lhs)`,` type($rhs) (`,` 
type($acc)^)?  `->` type($result)
+  }];
+
+  let hasVerifier = 1;
+}
+
+def XeGPU_AtomicRMWOp: XeGPU_Op<"atomic_rmw", [Pure,
+  AllElementTypesMatch<["tensorDesc", "value", "result"]>,
+  AllShapesMatch<["tensorDesc", "mask", "value", "result"]>]> {
+  let summary = "A ready-modify-write operation. ";
+
+  let description = [{
+`AtomicRMWOp` has same semantic to `memref.atomic_rmw`, except that
+it work on a `TensorDescType` object while `memref.atomic_rmw` works
+on a `MemRefType` object. It also has a `mask` variable, which has the
+same shape with `TensorDesc`, to enable or disable some data points of
+the `TensorDesc`.
+  }];
+
+  let arguments = (ins
+AtomicRMWKindAttr:$kind,
+XeGPU_TensorDesc:$tensorDesc,
+XeGPU_MaskType:$mask,
+XeGPU_ValueType:$value);
+
+  let results = (outs XeGPU_ValueType:$result);
+
+  let assemblyFormat = [{
+$kind $tensorDesc `,` $mask `,` $value attr-dict `:`
+type($tensorDesc) `,` type($mask) `,` type($value) `->` type($result)
+  }];
+}
+
+def XeGPU_AllocNbarrierOp: XeGPU_Op<"alloc_nbarrier", []> {
+  let summary = "It allocates a set of named barriers.";
+  let description = [{AllocNbarrier is to create a set of named barriers as
+  specified by `nbarrier_num`. Named barriers are workgroup level resources,
+and are shared by all threads in the workgroup. For example, there are
+up to 32 barriers (range 0-31) for each Xecore on PVC. A typical use case

adam-smnk wrote:

```suggestion
up to 32 barriers (range 0-31) for each XeCore on PVC. A typical use case
```

https://github.com/llvm/llvm-project/pull/88439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [mlir] Add dpas and named barrier ops (PR #88439)

[Adam Siemieniuk via llvm-branch-commits]

@@ -662,4 +662,152 @@ def XeGPU_UpdateOffsetOp: XeGPU_Op<"update_offset",
   }];
 }
 
+def XeGPU_DpasOp : XeGPU_Op<"dpas", [Pure, AllElementTypesMatch<["lhs", 
"rhs"]>]> {
+  let summary = "It performs mma computation";
+
+  let description = [{DPAS performs matrix multiplication on matrix A of `mxk`
+size, B of `kxn` size, and accumulate on matrix C of `mxn` to the same size
+matrix , `m=8`, `n=16` and `k=8 * 32/bit_width_of_elem_type`. So for fp16
+data type, the matrices are `A: vector<8x16xf16>`, `B: vector<16x16xf16>`,
+and `C/D: vector<8x16xf32>`. Besides the matrix size requirements, DPAS
+also requires A and B to be loaded with the required data layout. 
Specially,
+VNNI layout is required for B operand. It is achieved via setting 
`vnni_axis = 0`
+of the corresponding `load_nd` operator. To keep both operands as 3D 
vector,
+operand A is loaded via setting `vnni_axis = 1` without impacting the
+physical layouts change in register. Due to the VNNI transformation, A and 
B operands
+are represented as 3D vector, with the last dimension representing the 
VNNI factor,
+which is computed as `32/bit_width_of_elem_type`. Therefore, `A: 
vector<8x16xf16>`
+is represented as `A: vector<4x8x2xf16>`, and `B:vector<16x16xf16>` is

adam-smnk wrote:

```suggestion
is represented as `A: vector<8x8x2xf16>`, and `B: vector<16x16xf16>` is
```

https://github.com/llvm/llvm-project/pull/88439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] ca5fcbe - Revert "[flang][runtime] Add ACCESS library procedure (#88395)"

[via llvm-branch-commits]

Author: Tom Eccles
Date: 2024-04-12T13:49:19+01:00
New Revision: ca5fcbe0ea0e60381073b96dc898211efa42d533

URL: 
https://github.com/llvm/llvm-project/commit/ca5fcbe0ea0e60381073b96dc898211efa42d533
DIFF: 
https://github.com/llvm/llvm-project/commit/ca5fcbe0ea0e60381073b96dc898211efa42d533.diff

LOG: Revert "[flang][runtime] Add ACCESS library procedure (#88395)"

This reverts commit f220d26eb1ab5b588215acf538ca82bb3c8798cc.

Added: 


Modified: 
flang/docs/Intrinsics.md
flang/include/flang/Runtime/extensions.h
flang/runtime/extensions.cpp
flang/unittests/Runtime/CMakeLists.txt

Removed: 
flang/unittests/Runtime/AccessTest.cpp



diff  --git a/flang/docs/Intrinsics.md b/flang/docs/Intrinsics.md
index 848619cb65d909..ccb93e104dab65 100644
--- a/flang/docs/Intrinsics.md
+++ b/flang/docs/Intrinsics.md
@@ -657,14 +657,6 @@ CALL CO_REDUCE
 CALL CO_SUM
 ```
 
-### Inquiry Functions
-ACCESS (GNU extension) is not supported on Windows. Otherwise:
-```
-CHARACTER(LEN=*) :: path = 'path/to/file'
-IF (ACCESS(path, 'rwx')) &
-  ...
-```
-
 ## Non-standard intrinsics
 ### PGI
 ```

diff  --git a/flang/include/flang/Runtime/extensions.h 
b/flang/include/flang/Runtime/extensions.h
index fef651f3b2eedb..7d0952206fc195 100644
--- a/flang/include/flang/Runtime/extensions.h
+++ b/flang/include/flang/Runtime/extensions.h
@@ -44,12 +44,5 @@ std::int64_t RTNAME(Signal)(std::int64_t number, void 
(*handler)(int));
 // GNU extension subroutine SLEEP(SECONDS)
 void RTNAME(Sleep)(std::int64_t seconds);
 
-// GNU extension function ACCESS(NAME, MODE)
-// TODO: not supported on Windows
-#ifndef _WIN32
-std::int64_t FORTRAN_PROCEDURE_NAME(access)(const char *name,
-std::int64_t nameLength, const char *mode, std::int64_t modeLength);
-#endif
-
 } // extern "C"
 #endif // FORTRAN_RUNTIME_EXTENSIONS_H_

diff  --git a/flang/runtime/extensions.cpp b/flang/runtime/extensions.cpp
index 12498b502ae1cf..3ac98000335d7d 100644
--- a/flang/runtime/extensions.cpp
+++ b/flang/runtime/extensions.cpp
@@ -17,7 +17,6 @@
 #include "flang/Runtime/entry-names.h"
 #include "flang/Runtime/io-api.h"
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -139,77 +138,5 @@ void RTNAME(Sleep)(std::int64_t seconds) {
   std::this_thread::sleep_for(std::chrono::seconds(seconds));
 }
 
-// TODO: not supported on Windows
-#ifndef _WIN32
-std::int64_t FORTRAN_PROCEDURE_NAME(access)(const char *name,
-std::int64_t nameLength, const char *mode, std::int64_t modeLength) {
-  std::int64_t ret{-1};
-  if (nameLength <= 0 || modeLength <= 0 || !name || !mode) {
-return ret;
-  }
-
-  // ensure name is null terminated
-  char *newName{nullptr};
-  if (name[nameLength - 1] != '\0') {
-newName = static_cast(std::malloc(nameLength + 1));
-std::memcpy(newName, name, nameLength);
-newName[nameLength] = '\0';
-name = newName;
-  }
-
-  // calculate mode
-  bool read{false};
-  bool write{false};
-  bool execute{false};
-  bool exists{false};
-  int imode{0};
-
-  for (std::int64_t i = 0; i < modeLength; ++i) {
-switch (mode[i]) {
-case 'r':
-  read = true;
-  break;
-case 'w':
-  write = true;
-  break;
-case 'x':
-  execute = true;
-  break;
-case ' ':
-  exists = true;
-  break;
-default:
-  // invalid mode
-  goto cleanup;
-}
-  }
-  if (!read && !write && !execute && !exists) {
-// invalid mode
-goto cleanup;
-  }
-
-  if (!read && !write && !execute) {
-imode = F_OK;
-  } else {
-if (read) {
-  imode |= R_OK;
-}
-if (write) {
-  imode |= W_OK;
-}
-if (execute) {
-  imode |= X_OK;
-}
-  }
-  ret = access(name, imode);
-
-cleanup:
-  if (newName) {
-free(newName);
-  }
-  return ret;
-}
-#endif
-
 } // namespace Fortran::runtime
 } // extern "C"

diff  --git a/flang/unittests/Runtime/AccessTest.cpp 
b/flang/unittests/Runtime/AccessTest.cpp
deleted file mode 100644
index 5c8a634192d92b..00
--- a/flang/unittests/Runtime/AccessTest.cpp
+++ /dev/null
@@ -1,390 +0,0 @@
-//===-- flang/unittests/Runtime/AccessTest.cpp 
===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-// TODO: ACCESS is not yet implemented on Windows
-#ifndef _WIN32
-
-#include "CrashHandlerFixture.h"
-#include "gtest/gtest.h"
-#include "flang/Runtime/extensions.h"
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-namespace {
-
-struct AccessTests : public CrashHandlerFixture {};
-
-struct AccessType {
-  bool read{false};
-  bool write{false};
-  bool execute{false};
-  bool exists{false};
-};
-
-} // namespace
-
-static std::string addPIDSuffix(const char *name) {
-

[llvm-branch-commits] [mlir] [MLIR][XeGPU] Add dpas and named barrier ops (PR #88439)

[Chao Chen via llvm-branch-commits]

https://github.com/chencha3 edited 
https://github.com/llvm/llvm-project/pull/88439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman requested changes to this pull request.

I don't think we should add this to the 18.x release -- we're already getting 
requests from users to not do that: 
https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20240408/566402.html

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman milestoned 
https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Giuliano Belinassi via llvm-branch-commits]

giulianobelinassi wrote:

> I don't think we should add this to the 18.x release -- we're already getting 
> requests from users to not do that: 
> https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20240408/566402.html

This doesn't affect the number of spaces and it is not based on vgvassilev's 
patch.

The test case in question:
```
~/projects/llvm-project/llvm/build/bin/clang++ a.cpp -Xclang -ast-print -S -o -
template  class FinalTemplate;
```

This would only change the position of the `override` and `final` keywords.

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

I think the 18.1 behavior is already correct?

https://godbolt.org/z/v3G7h44E1

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Giuliano Belinassi via llvm-branch-commits]

giulianobelinassi wrote:

> I think the 18.1 behavior is already correct?
> 
> https://godbolt.org/z/v3G7h44E1

It is not:
https://godbolt.org/z/96rWese3P

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

AaronBallman wrote:

Ah that's right, it was with definitions that we ran into the issue! Sorry for 
being slow today. Okay, I retract my concerns, this is a safe and targeted fix.

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Aaron Ballman via llvm-branch-commits]

https://github.com/AaronBallman commented:

I think this is reasonable, but leaving it to @erichkeane to make the final 
call.

https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Fix override keyword being print to the left side (PR #88453)

[Erich Keane via llvm-branch-commits]

https://github.com/erichkeane approved this pull request.


https://github.com/llvm/llvm-project/pull/88453
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [compiler-rt] release/18.x: [RISCV] Support rv{32, 64}e in the compiler builtins (#88252) (PR #88525)

[via llvm-branch-commits]

https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/88525

Backport bd32aaa8c9ec2094f605315b3989adc2a567ca98

Requested by: @wangpc-pp

>From 67b171f24ffef4b4e8fd3882331cdf7327408580 Mon Sep 17 00:00:00 2001
From: Cyrill Leutwiler 
Date: Thu, 11 Apr 2024 07:11:51 +0200
Subject: [PATCH] [RISCV] Support rv{32, 64}e in the compiler builtins (#88252)

Register spills (save/restore) in RISC-V embedded work differently
because there are less registers and different stack alignment.

[GCC equivalent
](https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/save-restore.S#L298C16-L336)

Follow up from #76777.

-

Signed-off-by: xermicus 
(cherry picked from commit bd32aaa8c9ec2094f605315b3989adc2a567ca98)
---
 compiler-rt/lib/builtins/riscv/restore.S | 42 
 compiler-rt/lib/builtins/riscv/save.S| 42 
 2 files changed, 84 insertions(+)

diff --git a/compiler-rt/lib/builtins/riscv/restore.S 
b/compiler-rt/lib/builtins/riscv/restore.S
index 73f64a920d6698..6f43842c8ca684 100644
--- a/compiler-rt/lib/builtins/riscv/restore.S
+++ b/compiler-rt/lib/builtins/riscv/restore.S
@@ -22,6 +22,8 @@
 
 #if __riscv_xlen == 32
 
+#ifndef __riscv_32e
+
   .globl  __riscv_restore_12
   .type   __riscv_restore_12,@function
 __riscv_restore_12:
@@ -86,8 +88,29 @@ __riscv_restore_0:
   addisp, sp, 16
   ret
 
+#else
+
+  .globl  __riscv_restore_2
+  .type   __riscv_restore_2,@function
+  .globl  __riscv_restore_1
+  .type   __riscv_restore_1,@function
+  .globl  __riscv_restore_0
+  .type   __riscv_restore_0,@function
+__riscv_restore_2:
+__riscv_restore_1:
+__riscv_restore_0:
+  lw  s1,  0(sp)
+  lw  s0,  4(sp)
+  lw  ra,  8(sp)
+  addisp, sp, 12
+  ret
+
+#endif
+
 #elif __riscv_xlen == 64
 
+#ifndef __riscv_64e
+
   .globl  __riscv_restore_12
   .type   __riscv_restore_12,@function
 __riscv_restore_12:
@@ -161,6 +184,25 @@ __riscv_restore_0:
   addisp, sp, 16
   ret
 
+#else
+
+  .globl  __riscv_restore_2
+  .type   __riscv_restore_2,@function
+  .globl  __riscv_restore_1
+  .type   __riscv_restore_1,@function
+  .globl  __riscv_restore_0
+  .type   __riscv_restore_0,@function
+__riscv_restore_2:
+__riscv_restore_1:
+__riscv_restore_0:
+  ld  s1,  0(sp)
+  ld  s0,  8(sp)
+  ld  ra,  16(sp)
+  addisp, sp, 24
+  ret
+
+#endif
+
 #else
 # error "xlen must be 32 or 64 for save-restore implementation
 #endif
diff --git a/compiler-rt/lib/builtins/riscv/save.S 
b/compiler-rt/lib/builtins/riscv/save.S
index 85501aeb4c2e93..3e044179ff7f1d 100644
--- a/compiler-rt/lib/builtins/riscv/save.S
+++ b/compiler-rt/lib/builtins/riscv/save.S
@@ -18,6 +18,8 @@
 
 #if __riscv_xlen == 32
 
+#ifndef __riscv_32e
+
   .globl  __riscv_save_12
   .type   __riscv_save_12,@function
 __riscv_save_12:
@@ -92,8 +94,29 @@ __riscv_save_0:
   sw  ra,  12(sp)
   jr  t0
 
+#else
+
+  .globl  __riscv_save_2
+  .type   __riscv_save_2,@function
+  .globl  __riscv_save_1
+  .type   __riscv_save_1,@function
+  .globl  __riscv_save_0
+  .type   __riscv_save_0,@function
+__riscv_save_2:
+__riscv_save_1:
+__riscv_save_0:
+  addisp, sp, -12
+  sw  s1,  0(sp)
+  sw  s0,  4(sp)
+  sw  ra,  8(sp)
+  jr  t0
+
+#endif
+
 #elif __riscv_xlen == 64
 
+#ifndef __riscv_64e
+
   .globl  __riscv_save_12
   .type   __riscv_save_12,@function
 __riscv_save_12:
@@ -181,6 +204,25 @@ __riscv_save_0:
   sd ra, 8(sp)
   jr t0
 
+#else
+
+  .globl  __riscv_save_2
+  .type   __riscv_save_2,@function
+  .globl  __riscv_save_1
+  .type   __riscv_save_1,@function
+  .globl  __riscv_save_0
+  .type   __riscv_save_0,@function
+__riscv_save_2:
+__riscv_save_1:
+__riscv_save_0:
+  addi   sp, sp, -24
+  sd s1, 0(sp)
+  sd s0, 8(sp)
+  sd ra, 16(sp)
+  jr t0
+
+#endif
+
 #else
 # error "xlen must be 32 or 64 for save-restore implementation
 #endif

___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [compiler-rt] release/18.x: [RISCV] Support rv{32, 64}e in the compiler builtins (#88252) (PR #88525)

[via llvm-branch-commits]

https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/88525
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [compiler-rt] release/18.x: [RISCV] Support rv{32, 64}e in the compiler builtins (#88252) (PR #88525)

[via llvm-branch-commits]

llvmbot wrote:

@kito-cheng What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/88525
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Serialization] Code cleanups and polish 83233 (PR #83237)

[Ilya Biryukov via llvm-branch-commits]

ilya-biryukov wrote:

Sorry, still struggling to get a small repro. The build graphs we have are 
quite large, unfortunately.
Did any of the stack traces or error message I posted help to find certain 
problems? Or is there no hope until we get a smaller repro?

https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libcxx] release/18.x: [libc++] Fix -Wgnu-include-next in stddef.h (#88214) (PR #88419)

[Mark de Wever via llvm-branch-commits]

https://github.com/mordante approved this pull request.


https://github.com/llvm/llvm-project/pull/88419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libcxx] release/18.x: [libcxx] coerce formatter precision to int (#87738) (PR #87801)

[Mark de Wever via llvm-branch-commits]

mordante wrote:

> > Is it OK to merge this with the failing test?
> 
> is it possible this was a fix for an XFAIL @mordante ?

This failure is in completely unrelated code. So I'm happy to merge it with the 
CI failure.

https://github.com/llvm/llvm-project/pull/87801
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libcxx] [libc++][format] Improves escaping performance. (PR #88533)

[via llvm-branch-commits]

llvmbot wrote:




@llvm/pr-subscribers-libcxx

Author: Mark de Wever (mordante)


Changes

The previous patch implemented
- P2713R1 Escaping improvements in std::format
- LWG3965 Incorrect example in [format.string.escaped] p3 for formatting of 
combining characters

These changes were correct, but has a size and performance penalty. This patch 
improves the size and performance of the previous patch. The performance is 
still worse than before since the lookups may require two property lookups 
instead of one before implementing the paper. The changes give a tighter 
coupling between the Unicode data and the algorithm. An additional tests are 
added to notify about changes in future Unicode updates.

Before
---
Benchmark Time CPU   Iterations
---
BM_ascii_escaped   110704 ns   110696 ns 6206
BM_unicode_escaped 101371 ns   101374 ns 6862
BM_cyrillic_escaped 63329 ns63327 ns11013
BM_japanese_escaped 41223 ns41225 ns16938
BM_emoji_escaped   111022 ns   111021 ns 6304
BM_ascii_escaped112441 ns   112443 ns 6231
BM_unicode_escaped  102776 ns   102779 ns 6813
BM_cyrillic_escaped  58977 ns58975 ns11868
BM_japanese_escaped  36885 ns36886 ns18975
BM_emoji_escaped115885 ns   115881 ns 6051

The first change is to manually encode the entire last area and make a manual 
exception for the 240 excluded entries. This reduced the table from 1077 to 729 
entries and gave the following benchmark results. 
---
Benchmark Time CPU   Iterations
---
BM_ascii_escaped   104777 ns   104776 ns 6550
BM_unicode_escaped  96980 ns96982 ns 7238
BM_cyrillic_escaped 60254 ns60251 ns11670
BM_japanese_escaped 44452 ns44452 ns15734
BM_emoji_escaped   104557 ns   104551 ns 6685
BM_ascii_escaped107456 ns   107454 ns 6505
BM_unicode_escaped   96219 ns96216 ns 7301
BM_cyrillic_escaped  56921 ns56904 ns12288
BM_japanese_escaped  39530 ns39529 ns17492
BM_emoji_escaped108494 ns   108496 ns 6408

An entry in the table can only contain 2048 code points. For larger ranges 
there are multiple entries split in chunks with a maximum size of 2048 entries. 
To encode the entire Unicode code point range 21 bits are required. The manual 
part starts at 0x323B0 this means all entries in the table fit in 18 bits. This 
allows to allocate 3 additional bits for the range. This allows entries to have 
16384 elements. This range always avoids splitting the range in multiple chunks.

This reduces the number of table elements from 729 to 711 and gives the 
following benchmark results.
---
Benchmark Time CPU   Iterations
---
BM_ascii_escaped   104289 ns   104289 ns 6619
BM_unicode_escaped  96682 ns96681 ns 7215
BM_cyrillic_escaped 59673 ns59673 ns11732
BM_japanese_escaped 41983 ns41982 ns16646
BM_emoji_escaped   104119 ns   104120 ns 6683
BM_ascii_escaped104503 ns   104505 ns 6693
BM_unicode_escaped   93426 ns93423 ns 7489
BM_cyrillic_escaped  54858 ns54859 ns12742
BM_japanese_escaped  36385 ns36384 ns19259
BM_emoji_escaped105608 ns   105610 ns 6592

---

Patch is 102.90 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/88533.diff


3 Files Affected:

- (modified) libcxx/include/__format/escaped_output_table.h (+729-1092) 
- (added) 
libcxx/test/libcxx/utilities/format/format.string/format.string.std/escaped_output.pass.cpp
 (+100) 
- (modified) libcxx/utils/generate_escaped_output_table.py (+51-35) 


``diff
diff --git a/libcxx/include/__format/escaped_output_table.h 
b/libcxx/include/__format/escaped_output_table.h
index 3144abdd3f9a80..6abe121661bdf6 100644
--- a/libcxx/include/__format/escaped_output_table.h
+++ b/libcxx/include/__format/escaped_output_table.

[llvm-branch-commits] [clang] [Serialization] Code cleanups and polish 83233 (PR #83237)

[Vassil Vassilev via llvm-branch-commits]

vgvassilev wrote:

Can you export all files into a standalone reproducer? I might be able to 
reduce an example. 

https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [compiler-rt] release/18.x: [RISCV] Support rv{32, 64}e in the compiler builtins (#88252) (PR #88525)

[Cyrill Leutwiler via llvm-branch-commits]

xermicus wrote:

compiler-rt doesn't build for RISC-V embedded targets without this patch so to 
me it'd make sense to backport :)

https://github.com/llvm/llvm-project/pull/88525
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libcxx] [libc++][TZDB] Adds sys_info formatter. (PR #85896)

[Mark de Wever via llvm-branch-commits]

https://github.com/mordante updated 
https://github.com/llvm/llvm-project/pull/85896

>From e6ae1f07641b79b63b772b866176ffef94a25d48 Mon Sep 17 00:00:00 2001
From: Mark de Wever 
Date: Sun, 10 Mar 2024 17:49:39 +0100
Subject: [PATCH] [libc++][TZDB] Adds sys_info formatter.

Implements parts of:
- P0355 Extending  to Calendars and Time Zones
- P1361 Integration of chrono with text formatting
---
 libcxx/docs/Status/FormatPaper.csv|   2 +-
 libcxx/include/__chrono/convert_to_tm.h   |   5 +
 libcxx/include/__chrono/formatter.h   |  46 +-
 libcxx/include/__chrono/ostream.h |  20 +++
 libcxx/include/__chrono/sys_info.h|   2 +-
 libcxx/include/chrono |   5 +
 .../time.zone.info.sys/ostream.pass.cpp   |  74 ++
 .../time/time.syn/formatter.sys_info.pass.cpp | 137 ++
 .../time.zone.info.sys/ostream.pass.cpp   |  52 +++
 .../concept.formattable.compile.pass.cpp  |   5 +-
 libcxx/test/support/test_macros.h |   8 +
 11 files changed, 350 insertions(+), 6 deletions(-)
 create mode 100644 
libcxx/test/libcxx/time/time.zone/time.zone.info/time.zone.info.sys/ostream.pass.cpp
 create mode 100644 libcxx/test/std/time/time.syn/formatter.sys_info.pass.cpp
 create mode 100644 
libcxx/test/std/time/time.zone/time.zone.info/time.zone.info.sys/ostream.pass.cpp

diff --git a/libcxx/docs/Status/FormatPaper.csv 
b/libcxx/docs/Status/FormatPaper.csv
index e9d407e79e2539..8ace18815f5375 100644
--- a/libcxx/docs/Status/FormatPaper.csv
+++ b/libcxx/docs/Status/FormatPaper.csv
@@ -24,7 +24,7 @@ Section,Description,Dependencies,Assignee,Status,First 
released version
 `[time.syn] `_,"Formatter 
``chrono::year_month_weekday``",,Mark de Wever,|Complete|,16.0
 `[time.syn] `_,"Formatter 
``chrono::year_month_weekday_last``",,Mark de Wever,|Complete|,16.0
 `[time.syn] `_,"Formatter 
``chrono::hh_mm_ss>``",,Mark de Wever,|Complete|,17.0
-`[time.syn] `_,"Formatter ``chrono::sys_info``",A 
 implementation,Mark de Wever,,
+`[time.syn] `_,"Formatter 
``chrono::sys_info``",,Mark de Wever,|Complete|,19.0
 `[time.syn] `_,"Formatter 
``chrono::local_info``",A  implementation,Mark de Wever,,
 `[time.syn] `_,"Formatter 
``chrono::zoned_time``",A  
implementation,Mark de Wever,,
 
diff --git a/libcxx/include/__chrono/convert_to_tm.h 
b/libcxx/include/__chrono/convert_to_tm.h
index 1301cd6f1f1ada..d2c5cf922ba671 100644
--- a/libcxx/include/__chrono/convert_to_tm.h
+++ b/libcxx/include/__chrono/convert_to_tm.h
@@ -20,6 +20,7 @@
 #include <__chrono/month_weekday.h>
 #include <__chrono/monthday.h>
 #include <__chrono/statically_widen.h>
+#include <__chrono/sys_info.h>
 #include <__chrono/system_clock.h>
 #include <__chrono/time_point.h>
 #include <__chrono/weekday.h>
@@ -171,6 +172,10 @@ _LIBCPP_HIDE_FROM_ABI _Tm __convert_to_tm(const _ChronoT& 
__value) {
   if (__value.hours().count() > 
std::numeric_limits::max())
 std::__throw_format_error("Formatting hh_mm_ss, encountered an hour 
overflow");
 __result.tm_hour = __value.hours().count();
+#  if !defined(_LIBCPP_HAS_NO_INCOMPLETE_TZDB)
+  } else if constexpr (same_as<_ChronoT, chrono::sys_info>) {
+// Has no time information.
+#  endif
   } else
 static_assert(sizeof(_ChronoT) == 0, "Add the missing type 
specialization");
 
diff --git a/libcxx/include/__chrono/formatter.h 
b/libcxx/include/__chrono/formatter.h
index 217979e88c93db..e3235a9b5b5cf5 100644
--- a/libcxx/include/__chrono/formatter.h
+++ b/libcxx/include/__chrono/formatter.h
@@ -24,6 +24,7 @@
 #include <__chrono/ostream.h>
 #include <__chrono/parser_std_format_spec.h>
 #include <__chrono/statically_widen.h>
+#include <__chrono/sys_info.h>
 #include <__chrono/system_clock.h>
 #include <__chrono/time_point.h>
 #include <__chrono/weekday.h>
@@ -185,10 +186,11 @@ __format_zone_offset(basic_stringstream<_CharT>& __sstr, 
chrono::seconds __offse
 
   chrono::hh_mm_ss __hms{__offset};
   std::ostreambuf_iterator<_CharT> __out_it{__sstr};
+  // Note HMS does not allow formatting hours > 23, but the offset is not 
limited to 24H.
+  std::format_to(__out_it, _LIBCPP_STATICALLY_WIDEN(_CharT, "{:02}"), 
__hms.hours().count());
   if (__modifier)
-std::format_to(__out_it, _LIBCPP_STATICALLY_WIDEN(_CharT, "{:%H:%M}"), 
__hms);
-  else
-std::format_to(__out_it, _LIBCPP_STATICALLY_WIDEN(_CharT, "{:%H%M}"), 
__hms);
+__sstr << _CharT(':');
+  std::format_to(__out_it, _LIBCPP_STATICALLY_WIDEN(_CharT, "{:02}"), 
__hms.minutes().count());
 }
 
 // Helper to store the time zone information needed for formatting.
@@ -202,6 +204,12 @@ struct _LIBCPP_HIDE_FROM_ABI __time_zone {
 template 
 _LIBCPP_HIDE_FROM_ABI __time_zone __convert_to_time_zone([[maybe_unused]] 
const _Tp& __value) {
   __time_zone __

[llvm-branch-commits] [runtimes] Allow building against an installed LLVM tree (PR #86209)

[Alexander Richardson via llvm-branch-commits]

https://github.com/arichardson updated 
https://github.com/llvm/llvm-project/pull/86209


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [runtimes] Allow building against an installed LLVM tree (PR #86209)

[Alexander Richardson via llvm-branch-commits]

https://github.com/arichardson updated 
https://github.com/llvm/llvm-project/pull/86209


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [runtimes] Allow building against an installed LLVM tree (PR #86209)

[Alexander Richardson via llvm-branch-commits]

@@ -218,6 +218,22 @@ foreach(entry ${runtimes})
 endforeach()
 
 if(LLVM_INCLUDE_TESTS)
+  # Add lit if needed before adding any runtimes since their CMake tests
+  # configuration might depend on lit being present.
+  if (NOT HAVE_LLVM_LIT)
+# If built by manually invoking cmake on this directory, we don't have
+# llvm-lit. If invoked via llvm/runtimes, the toplevel llvm cmake
+# invocation already generated the llvm-lit script.
+set(LLVM_LIT_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin)
+add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
+ ${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
+# Ensure that the testsuites use the local lit rather than
+# LLVM_INSTALL_DIR/bin/llvm-lit (which may not exist if LLVM_BINARY_DIR
+# points at an installed LLVM tree rather than a build tree.
+get_llvm_lit_path(_base_dir _file_name)
+set(LLVM_EXTERNAL_LIT "${_base_dir}/${_file_name}" CACHE STRING "Command 
used to spawn lit" FORCE)

arichardson wrote:

Sorry for the delay here, was waiting to land the dependent PRs. Updated now.

https://github.com/llvm/llvm-project/pull/86209
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: Prepend all library intrinsics with `#` when building for Arm64EC (PR #88016)

[Daniel Paoliello via llvm-branch-commits]

dpaoliello wrote:

@tstellar this is ready to land for 18

https://github.com/llvm/llvm-project/pull/88016
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits