[llvm-branch-commits] [llvm] 133d368 - Revert "[Utils] Add new --update-tests flag to llvm-lit (#108425)"
Author: Henrik G. Olsson
Date: 2024-10-01T17:14:31-07:00
New Revision: 133d368b16d11e44bc3fca92a042cf5ad0ce8dd1
URL:
https://github.com/llvm/llvm-project/commit/133d368b16d11e44bc3fca92a042cf5ad0ce8dd1
DIFF:
https://github.com/llvm/llvm-project/commit/133d368b16d11e44bc3fca92a042cf5ad0ce8dd1.diff
LOG: Revert "[Utils] Add new --update-tests flag to llvm-lit (#108425)"
This reverts commit bb8b9ac0ba5382bcf02f614b5b3a84c3699cf52c.
Added:
Modified:
clang/test/lit.cfg.py
llvm/docs/CommandGuide/lit.rst
llvm/test/lit.cfg.py
llvm/utils/lit/lit/LitConfig.py
llvm/utils/lit/lit/TestRunner.py
llvm/utils/lit/lit/cl_arguments.py
llvm/utils/lit/lit/llvm/config.py
llvm/utils/lit/lit/main.py
llvm/utils/update_any_test_checks.py
Removed:
diff --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index 32ed5239b90795..92a3361ce672e2 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -362,13 +362,3 @@ def calculate_arch_features(arch_string):
# possibly be present in system and user configuration files, so disable
# default configs for the test runs.
config.environment["CLANG_NO_DEFAULT_CONFIG"] = "1"
-
-if lit_config.update_tests:
-import sys
-import os
-
-utilspath = os.path.join(config.llvm_src_root, "utils")
-sys.path.append(utilspath)
-from update_any_test_checks import utc_lit_plugin
-
-lit_config.test_updaters.append(utc_lit_plugin)
diff --git a/llvm/docs/CommandGuide/lit.rst b/llvm/docs/CommandGuide/lit.rst
index dadecef567b7c9..c9d5baba3e2f49 100644
--- a/llvm/docs/CommandGuide/lit.rst
+++ b/llvm/docs/CommandGuide/lit.rst
@@ -313,11 +313,6 @@ ADDITIONAL OPTIONS
List all of the discovered tests and exit.
-.. option:: --update-tests
-
- Pass failing tests to functions in the ``lit_config.update_tests`` list to
- check whether any of them know how to update the test to make it pass.
-
EXIT STATUS
---
diff --git a/llvm/test/lit.cfg.py b/llvm/test/lit.cfg.py
index 1d5b2bcae1b766..5a03a85386e0aa 100644
--- a/llvm/test/lit.cfg.py
+++ b/llvm/test/lit.cfg.py
@@ -630,13 +630,3 @@ def have_ld64_plugin_support():
if config.has_logf128:
config.available_features.add("has_logf128")
-
-if lit_config.update_tests:
-import sys
-import os
-
-utilspath = os.path.join(config.llvm_src_root, "utils")
-sys.path.append(utilspath)
-from update_any_test_checks import utc_lit_plugin
-
-lit_config.test_updaters.append(utc_lit_plugin)
diff --git a/llvm/utils/lit/lit/LitConfig.py b/llvm/utils/lit/lit/LitConfig.py
index 198a2bf3172330..5dc712ae28370c 100644
--- a/llvm/utils/lit/lit/LitConfig.py
+++ b/llvm/utils/lit/lit/LitConfig.py
@@ -38,7 +38,6 @@ def __init__(
parallelism_groups={},
per_test_coverage=False,
gtest_sharding=True,
-update_tests=False,
):
# The name of the test runner.
self.progname = progname
@@ -90,8 +89,6 @@ def __init__(
self.parallelism_groups = parallelism_groups
self.per_test_coverage = per_test_coverage
self.gtest_sharding = bool(gtest_sharding)
-self.update_tests = update_tests
-self.test_updaters = []
@property
def maxIndividualTestTime(self):
diff --git a/llvm/utils/lit/lit/TestRunner.py
b/llvm/utils/lit/lit/TestRunner.py
index 3a2cdc5026b0c2..a1785073547ad0 100644
--- a/llvm/utils/lit/lit/TestRunner.py
+++ b/llvm/utils/lit/lit/TestRunner.py
@@ -1190,18 +1190,6 @@ def executeScriptInternal(
str(result.timeoutReached),
)
-if litConfig.update_tests:
-for test_updater in litConfig.test_updaters:
-try:
-update_output = test_updater(result, test)
-except Exception as e:
-out += f"Exception occurred in test updater: {e}"
-continue
-if update_output:
-for line in update_output.splitlines():
-out += f"# {line}\n"
-break
-
return out, err, exitCode, timeoutInfo
diff --git a/llvm/utils/lit/lit/cl_arguments.py
b/llvm/utils/lit/lit/cl_arguments.py
index dcbe553c6d4827..ed78256ee414b4 100644
--- a/llvm/utils/lit/lit/cl_arguments.py
+++ b/llvm/utils/lit/lit/cl_arguments.py
@@ -204,12 +204,6 @@ def parse_args():
action="store_true",
help="Exit with status zero even if some tests fail",
)
-execution_group.add_argument(
-"--update-tests",
-dest="update_tests",
-action="store_true",
-help="Try to update regression tests to reflect current behavior, if
possible",
-)
execution_test_time_group = execution_group.add_mutually_exclusive_group()
execution_test_time_group.add_argument(
"--skip-test-time-recording",
diff --git a/llvm/utils/lit/lit/llvm/config.py
b/llvm/utils/lit/lit
[llvm-branch-commits] [libcxx] Workaround for build error after #108999 (PR #110783)
https://github.com/vitalybuka edited https://github.com/llvm/llvm-project/pull/110783 ___ 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] Workaround for build error after #108999 (PR #110783)
llvmbot wrote: @llvm/pr-subscribers-libcxx Author: Vitaly Buka (vitalybuka) Changes ``` FAILED: include/c++/v1/libcxx.imp ./libcxx_build_msan/include/c++/v1/libcxx.imp cd ./libcxx_build_msan/libcxx/include && /usr/bin/python3 ./llvm-project/libcxx/utils/generate_iwyu_mapping.py -o ./libcxx_build_msan/include/c++/v1/libcxx.imp Traceback (most recent call last): File "./llvm-project/libcxx/utils/generate_iwyu_mapping.py", line 94, inmain(sys.argv[1:]) File "./llvm-project/libcxx/utils/generate_iwyu_mapping.py", line 84, in main raise RuntimeError(f"{header}: Header {public} is not a valid header") RuntimeError: __cxx03/__algorithm/all_of.h: Header cxx03 is not a valid header ninja: build stopped: subcommand failed. ``` --- Full diff: https://github.com/llvm/llvm-project/pull/110783.diff 1 Files Affected: - (modified) libcxx/utils/generate_iwyu_mapping.py (+1) ``diff diff --git a/libcxx/utils/generate_iwyu_mapping.py b/libcxx/utils/generate_iwyu_mapping.py index 599201808bb79b..dadf6b58bd98a8 100644 --- a/libcxx/utils/generate_iwyu_mapping.py +++ b/libcxx/utils/generate_iwyu_mapping.py @@ -15,6 +15,7 @@ def IWYU_mapping(header: str) -> typing.Optional[typing.List[str]]: "__pstl/.+", "__support/.+", "__utility/private_constructor_tag.h", +"__cxx03/.+", # FIXME: Workaround for https://github.com/llvm/llvm-project/pull/108999 ] if any(re.match(pattern, header) for pattern in ignore): return None `` https://github.com/llvm/llvm-project/pull/110783 ___ 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] Workaround for build error after #108999 (PR #110783)
github-actions[bot] wrote: :warning: Python code formatter, darker found issues in your code. :warning: You can test this locally with the following command: ``bash darker --check --diff -r af5ab7ff2c86ff2c3d02cbb3591b22d7b968d98b...c2bcf7a16daa701f72e5007ebda5a08d59f0c346 libcxx/utils/generate_iwyu_mapping.py `` View the diff from darker here. ``diff --- generate_iwyu_mapping.py2024-10-02 02:39:10.00 + +++ generate_iwyu_mapping.py2024-10-02 02:42:51.297193 + @@ -13,11 +13,11 @@ "__debug_utils/.+", "__fwd/get[.]h", "__pstl/.+", "__support/.+", "__utility/private_constructor_tag.h", -"__cxx03/.+", # FIXME: Workaround for https://github.com/llvm/llvm-project/pull/108999 +"__cxx03/.+", # FIXME: Workaround for https://github.com/llvm/llvm-project/pull/108999 ] if any(re.match(pattern, header) for pattern in ignore): return None elif header == "__bits": return ["bits"] `` https://github.com/llvm/llvm-project/pull/110783 ___ 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] Workaround for build error after #108999 (PR #110783)
https://github.com/vitalybuka created
https://github.com/llvm/llvm-project/pull/110783
```
FAILED: include/c++/v1/libcxx.imp ./libcxx_build_msan/include/c++/v1/libcxx.imp
cd ./libcxx_build_msan/libcxx/include && /usr/bin/python3
./llvm-project/libcxx/utils/generate_iwyu_mapping.py -o
./libcxx_build_msan/include/c++/v1/libcxx.imp
Traceback (most recent call last):
File "./llvm-project/libcxx/utils/generate_iwyu_mapping.py", line 94, in
main(sys.argv[1:])
File "./llvm-project/libcxx/utils/generate_iwyu_mapping.py", line 84, in main
raise RuntimeError(f"{header}: Header {public} is not a valid header")
RuntimeError: __cxx03/__algorithm/all_of.h: Header cxx03 is not a valid header
ninja: build stopped: subcommand failed.
```
___
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] AMDGPU: Handle folding frame indexes into add with immediate (PR #110738)
https://github.com/arsenm updated
https://github.com/llvm/llvm-project/pull/110738
>From 295561a4936e932aa41fe7d80ec2aafb94f49a8e Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Tue, 1 Oct 2024 23:53:51 +0400
Subject: [PATCH 1/2] AMDGPU: Handle folding frame indexes into add with
immediate
Frame index materialization can fold the constant offset into
adds with immediates. The mubuf expansion is more complicated because
we have to also insert the shift, so restrict this to one use for now.
This is preparation to avoid regressions in a future patch.
This also misses some cases due to visitation order. It depends on
the immediate already folding into the instruction.
---
llvm/lib/Target/AMDGPU/SIFoldOperands.cpp | 14 ++
llvm/test/CodeGen/AMDGPU/flat-scratch.ll | 6 ++
.../AMDGPU/fold-operands-frame-index.gfx10.mir | 3 +--
.../AMDGPU/fold-operands-frame-index.mir | 18 ++
.../materialize-frame-index-sgpr.gfx10.ll | 6 +++---
.../AMDGPU/materialize-frame-index-sgpr.ll | 12 ++--
6 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
index 1e2c77b08b9a63..fea84247f5ad88 100644
--- a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
+++ b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
@@ -194,6 +194,20 @@ bool SIFoldOperandsImpl::frameIndexMayFold(
return false;
const unsigned Opc = UseMI.getOpcode();
+ switch (Opc) {
+ case AMDGPU::S_ADD_I32:
+ case AMDGPU::V_ADD_U32_e32:
+ case AMDGPU::V_ADD_CO_U32_e32:
+// TODO: Handle e64 variants
+// TODO: Possibly relax hasOneUse. It matters more for mubuf, since we have
+// to insert the wave size shift at every point we use the index.
+// TODO: Fix depending on visit order to fold immediates into the operand
+return UseMI.getOperand(OpNo == 1 ? 2 : 1).isImm() &&
+ MRI->hasOneNonDBGUse(UseMI.getOperand(OpNo).getReg());
+ default:
+break;
+ }
+
if (TII->isMUBUF(UseMI))
return OpNo == AMDGPU::getNamedOperandIdx(Opc, AMDGPU::OpName::vaddr);
if (!TII->isFLATScratch(UseMI))
diff --git a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
index ef9590b3fd33fa..af0b6360527016 100644
--- a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
+++ b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
@@ -4705,8 +4705,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s0
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s1
; GFX10-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-NEXT:s_movk_i32 s0, 0x810
-; GFX10-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-NEXT:v_mov_b32_e32 v1, v0
; GFX10-NEXT:v_mov_b32_e32 v2, v0
; GFX10-NEXT:v_mov_b32_e32 v3, v0
@@ -4823,8 +4822,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s2
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s3
; GFX10-PAL-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-PAL-NEXT:s_movk_i32 s0, 0x810
-; GFX10-PAL-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-PAL-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-PAL-NEXT:v_mov_b32_e32 v1, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v2, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v3, v0
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
index 0d6511cbfceb21..b46c672ea8edd2 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
@@ -13,8 +13,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__v_add_u32_e32__const_v_fi
-; CHECK: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 %stack.0,
implicit $exec
-; CHECK-NEXT: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128,
[[V_MOV_B32_e32_]], implicit $exec
+; CHECK: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128, %stack.0,
implicit $exec
; CHECK-NEXT: $vgpr0 = COPY [[V_ADD_U32_e32_]]
; CHECK-NEXT: SI_RETURN implicit $vgpr0
%0:vgpr_32 = V_MOV_B32_e32 %stack.0, implicit $exec
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
index aa91a4f9f988fc..97ba179afbbe03 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
@@ -14,8 +14,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__s_add_i32__fi_const
-; CHECK: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 %stack.0
-; CHECK-NEXT: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 [[S_MOV_B32_]],
128, implicit-def $scc
+; CHECK: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 %stack.0, 128,
implicit-def $scc
; CHECK-NEXT: $sgpr4 = COPY [[S_ADD_I32_]]
; CHECK-NEXT: SI_RETURN implicit $s
[llvm-branch-commits] [libcxx] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/110677
Backport 677e8cd6ff51e178bcb4669104763f71a2de106c
Requested by: @ldionne
>From c571c9a9b34863d272a99e0b4a7a9cca619da459 Mon Sep 17 00:00:00 2001
From: Louis Dionne
Date: Tue, 1 Oct 2024 09:39:44 -0400
Subject: [PATCH] [libc++] Avoid re-exporting a few specific symbols from
libc++abi (#109054)
In 6a884a9aef39, I synchronized the export list of libc++abi to the
export list of libc++. From the linker's perspective, this caused these
symbols to be taken from libc++.dylib instead of libc++abi.dylib.
However, that can be problematic when back-deploying. Indeed, this means
that the linker will encode an undefined reference to be fullfilled by
libc++.dylib, but when backdeploying against an older system, that
symbol might only be available in libc++abi.dylib.
Most of the symbols that started being re-exported after 6a884a9aef39
turn out to be implementation details of libc++abi, so nobody really
depends on them and this back-deployment issue is inconsequential.
However, we ran into issues with a few of these symbols while testing
LLVM 19, which led to this patch. This slipped between the cracks and
that is why the patch is coming so long after the original patch landed.
In the future, a follow-up cleanup would be to stop exporting most of
the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
since they are implementation details that nobody should be relying on.
rdar://131984512
(cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c)
---
libcxx/lib/abi/CHANGELOG.TXT | 30 +++
...bcxxabi.v1.stable.exceptions.nonew.abilist | 7 -
...bcxxabi.v1.stable.exceptions.nonew.abilist | 7 -
libcxxabi/lib/cxxabiv1.exp| 3 --
libcxxabi/lib/itanium-base.exp| 1 -
libcxxabi/lib/symbols-not-reexported.exp | 13
libcxxabi/src/CMakeLists.txt | 10 ++-
7 files changed, 52 insertions(+), 19 deletions(-)
create mode 100644 libcxxabi/lib/symbols-not-reexported.exp
diff --git a/libcxx/lib/abi/CHANGELOG.TXT b/libcxx/lib/abi/CHANGELOG.TXT
index 32526f1786c6d9..68c9d980a016ea 100644
--- a/libcxx/lib/abi/CHANGELOG.TXT
+++ b/libcxx/lib/abi/CHANGELOG.TXT
@@ -16,6 +16,36 @@ New entries should be added directly below the "Version"
header.
Version 19.0
+* [libc++] Avoid re-exporting a few specific symbols from libc++abi
+
+ In 6a884a9aef39, I synchronized the export list of libc++abi to the
+ export list of libc++. From the linker's perspective, this caused
+ these symbols to be taken from libc++.dylib instead of libc++abi.dylib.
+
+ However, that can be problematic when back-deploying. Indeed, this means
+ that the linker will encode an undefined reference to be fullfilled by
+ libc++.dylib, but when backdeploying against an older system, that symbol
+ might only be available in libc++abi.dylib.
+
+ Most of the symbols that started being re-exported after 6a884a9aef39
+ turn out to be implementation details of libc++abi, so nobody really
+ depends on them and this back-deployment issue is inconsequential.
+
+ However, we ran into issues with a few of these symbols while testing
+ LLVM 19, which led to this patch.
+
+ In the future, a follow-up cleanup would be to stop exporting most of
+ the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
+ since they are implementation details that nobody should be relying
+ on.
+
+ -apple-darwin
+ ---
+ Symbol not reexported anymore: ___cxa_rethrow_primary_exception
+ Symbol not reexported anymore: __ZTIN10__cxxabiv117__class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv120__si_class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv121__vmi_class_type_infoE
+
* [libc++] Always keep libc++abi re-exports up-to-date
This patch makes sure that the set of libc++abi symbols re-exported from
libc++
diff --git
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
index 917388f86811fe..32acae46e292d7 100644
---
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
+++
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
@@ -78,12 +78,9 @@
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__enum_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__shim_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__array_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__class_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__pbase_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv119__pointer_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv120__functi
[llvm-branch-commits] [llvm] [AArch64][PAC] Move emission of LR checks in tail calls to AsmPrinter (PR #110705)
atrosinenko wrote: > [!WARNING] > This pull request is not mergeable via GitHub because a downstack PR is > open. Once all requirements are satisfied, merge this PR as a stack href="https://app.graphite.dev/github/pr/llvm/llvm-project/110705?utm_source=stack-comment-downstack-mergeability-warning"; > >on Graphite. > https://graphite.dev/docs/merge-pull-requests";>Learn more * **#110705** https://app.graphite.dev/github/pr/llvm/llvm-project/110705?utm_source=stack-comment-icon"; target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="10px" height="10px"/> 👈 * **#110702** https://app.graphite.dev/github/pr/llvm/llvm-project/110702?utm_source=stack-comment-icon"; target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="10px" height="10px"/> * `main` This stack of pull requests is managed by Graphite. https://stacking.dev/?utm_source=stack-comment";>Learn more about stacking. Join @atrosinenko and the rest of your teammates on https://graphite.dev?utm-source=stack-comment";>https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="11px" height="11px"/> Graphite https://github.com/llvm/llvm-project/pull/110705 ___ 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] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
llvmbot wrote:
@llvm/pr-subscribers-libcxxabi
Author: None (llvmbot)
Changes
Backport 677e8cd6ff51e178bcb4669104763f71a2de106c
Requested by: @ldionne
---
Full diff: https://github.com/llvm/llvm-project/pull/110677.diff
7 Files Affected:
- (modified) libcxx/lib/abi/CHANGELOG.TXT (+30)
- (modified)
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
(-7)
- (modified)
libcxx/lib/abi/x86_64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
(-7)
- (modified) libcxxabi/lib/cxxabiv1.exp (-3)
- (modified) libcxxabi/lib/itanium-base.exp (-1)
- (added) libcxxabi/lib/symbols-not-reexported.exp (+13)
- (modified) libcxxabi/src/CMakeLists.txt (+9-1)
``diff
diff --git a/libcxx/lib/abi/CHANGELOG.TXT b/libcxx/lib/abi/CHANGELOG.TXT
index 32526f1786c6d9..68c9d980a016ea 100644
--- a/libcxx/lib/abi/CHANGELOG.TXT
+++ b/libcxx/lib/abi/CHANGELOG.TXT
@@ -16,6 +16,36 @@ New entries should be added directly below the "Version"
header.
Version 19.0
+* [libc++] Avoid re-exporting a few specific symbols from libc++abi
+
+ In 6a884a9aef39, I synchronized the export list of libc++abi to the
+ export list of libc++. From the linker's perspective, this caused
+ these symbols to be taken from libc++.dylib instead of libc++abi.dylib.
+
+ However, that can be problematic when back-deploying. Indeed, this means
+ that the linker will encode an undefined reference to be fullfilled by
+ libc++.dylib, but when backdeploying against an older system, that symbol
+ might only be available in libc++abi.dylib.
+
+ Most of the symbols that started being re-exported after 6a884a9aef39
+ turn out to be implementation details of libc++abi, so nobody really
+ depends on them and this back-deployment issue is inconsequential.
+
+ However, we ran into issues with a few of these symbols while testing
+ LLVM 19, which led to this patch.
+
+ In the future, a follow-up cleanup would be to stop exporting most of
+ the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
+ since they are implementation details that nobody should be relying
+ on.
+
+ -apple-darwin
+ ---
+ Symbol not reexported anymore: ___cxa_rethrow_primary_exception
+ Symbol not reexported anymore: __ZTIN10__cxxabiv117__class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv120__si_class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv121__vmi_class_type_infoE
+
* [libc++] Always keep libc++abi re-exports up-to-date
This patch makes sure that the set of libc++abi symbols re-exported from
libc++
diff --git
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
index 917388f86811fe..32acae46e292d7 100644
---
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
+++
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
@@ -78,12 +78,9 @@
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__enum_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__shim_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__array_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__class_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__pbase_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv119__pointer_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv120__function_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv120__si_class_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv121__vmi_class_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv123__fundamental_type_infoE',
'type': 'U'}
{'is_defined': False, 'name':
'__ZTIN10__cxxabiv129__pointer_to_member_type_infoE', 'type': 'U'}
{'is_defined': False, 'name': '__ZTIPDh', 'type': 'U'}
@@ -2002,12 +1999,9 @@
{'is_defined': True, 'name': '__ZTIN10__cxxabiv116__enum_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv116__shim_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__array_type_infoE', 'type':
'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__class_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__pbase_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv119__pointer_type_infoE',
'type': 'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv120__function_type_infoE',
'type': 'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv120__si_class_type_infoE',
'type': 'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv121__vmi_class_type_infoE',
'type': 'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv123__fundamental_type_infoE',
'type': 'I'}
{'is_defined': True, 'name':
[llvm-branch-commits] [clang] workflows/release-binaries: Use static ZSTD on macOS (PR #110701)
https://github.com/tstellar approved this pull request. https://github.com/llvm/llvm-project/pull/110701 ___ 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/19.x: Fix libFuzzer not building with pthreads on Windows (#109525) (PR #110663)
llvmbot wrote: @mstorsjo What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/110663 ___ 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] workflows/release-binaries: Use static ZSTD on macOS (PR #110701)
https://github.com/keith created
https://github.com/llvm/llvm-project/pull/110701
On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.
(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)
>From 303522ffc4552eb9182c07c5881a905bad071991 Mon Sep 17 00:00:00 2001
From: Keith Smiley
Date: Tue, 1 Oct 2024 10:02:20 -0700
Subject: [PATCH] workflows/release-binaries: Use static ZSTD on macOS
On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.
(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)
---
clang/cmake/caches/Release.cmake | 3 +++
1 file changed, 3 insertions(+)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 6d5f75ca0074ee..c4947bf453872b 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -101,3 +101,6 @@ set_final_stage_var(LLVM_ENABLE_PROJECTS
"${LLVM_RELEASE_ENABLE_PROJECTS}" STRIN
set_final_stage_var(CPACK_GENERATOR "TXZ" STRING)
set_final_stage_var(CPACK_ARCHIVE_THREADS "0" STRING)
+if(${CMAKE_HOST_SYSTEM_NAME} MATCHES "Darwin")
+ set_final_stage_var(LLVM_USE_STATIC_ZSTD "ON" BOOL)
+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] [clang] workflows/release-binaries: Use static ZSTD on macOS (PR #110701)
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Keith Smiley (keith)
Changes
On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.
(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)
---
Full diff: https://github.com/llvm/llvm-project/pull/110701.diff
1 Files Affected:
- (modified) clang/cmake/caches/Release.cmake (+3)
``diff
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 6d5f75ca0074ee..c4947bf453872b 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -101,3 +101,6 @@ set_final_stage_var(LLVM_ENABLE_PROJECTS
"${LLVM_RELEASE_ENABLE_PROJECTS}" STRIN
set_final_stage_var(CPACK_GENERATOR "TXZ" STRING)
set_final_stage_var(CPACK_ARCHIVE_THREADS "0" STRING)
+if(${CMAKE_HOST_SYSTEM_NAME} MATCHES "Darwin")
+ set_final_stage_var(LLVM_USE_STATIC_ZSTD "ON" BOOL)
+endif()
``
https://github.com/llvm/llvm-project/pull/110701
___
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] [AArch64][PAC] Move emission of LR checks in tail calls to AsmPrinter (PR #110705)
https://github.com/atrosinenko created
https://github.com/llvm/llvm-project/pull/110705
Move the emission of the checks performed on the authenticated LR value
during tail calls to AArch64AsmPrinter class, so that different checker
sequences can be reused by pseudo instructions expanded there.
This adds one more option to AuthCheckMethod enumeration, the generic
XPAC variant which is not restricted to checking the LR register.
Shorten the generic XPAC-based non-trapping sequence by one `mov`
instruction: perform XPAC on the tested register itself instead of the
scratch one as XPACLRI cannot operate on the scratch register anyway.
>From 60ca463dc41dc695a46a1fe86b571ace0d5dd391 Mon Sep 17 00:00:00 2001
From: Anatoly Trosinenko
Date: Mon, 23 Sep 2024 19:51:55 +0300
Subject: [PATCH] [AArch64][PAC] Move emission of LR checks in tail calls to
AsmPrinter
Move the emission of the checks performed on the authenticated LR value
during tail calls to AArch64AsmPrinter class, so that different checker
sequences can be reused by pseudo instructions expanded there.
This adds one more option to AuthCheckMethod enumeration, the generic
XPAC variant which is not restricted to checking the LR register.
Shorten the generic XPAC-based non-trapping sequence by one `mov`
instruction: perform XPAC on the tested register itself instead of the
scratch one as XPACLRI cannot operate on the scratch register anyway.
---
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 143 +++---
llvm/lib/Target/AArch64/AArch64InstrInfo.cpp | 13 ++
llvm/lib/Target/AArch64/AArch64InstrInfo.td | 2 +
.../lib/Target/AArch64/AArch64PointerAuth.cpp | 182 +-
llvm/lib/Target/AArch64/AArch64PointerAuth.h | 40 ++--
llvm/lib/Target/AArch64/AArch64Subtarget.cpp | 2 -
llvm/lib/Target/AArch64/AArch64Subtarget.h| 23 ---
llvm/test/CodeGen/AArch64/ptrauth-ret-trap.ll | 36 ++--
.../AArch64/sign-return-address-tailcall.ll | 54 +++---
9 files changed, 192 insertions(+), 303 deletions(-)
diff --git a/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
b/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
index 6d2dd0ecbccf31..50502477706ccf 100644
--- a/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ b/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -153,6 +153,7 @@ class AArch64AsmPrinter : public AsmPrinter {
void emitPtrauthCheckAuthenticatedValue(Register TestedReg,
Register ScratchReg,
AArch64PACKey::ID Key,
+ AArch64PAuth::AuthCheckMethod Method,
bool ShouldTrap,
const MCSymbol *OnFailure);
@@ -1731,7 +1732,8 @@ unsigned
AArch64AsmPrinter::emitPtrauthDiscriminator(uint16_t Disc,
/// of proceeding to the next instruction (only if ShouldTrap is false).
void AArch64AsmPrinter::emitPtrauthCheckAuthenticatedValue(
Register TestedReg, Register ScratchReg, AArch64PACKey::ID Key,
-bool ShouldTrap, const MCSymbol *OnFailure) {
+AArch64PAuth::AuthCheckMethod Method, bool ShouldTrap,
+const MCSymbol *OnFailure) {
// Insert a sequence to check if authentication of TestedReg succeeded,
// such as:
//
@@ -1757,38 +1759,70 @@ void
AArch64AsmPrinter::emitPtrauthCheckAuthenticatedValue(
//Lsuccess:
// ...
//
- // This sequence is expensive, but we need more information to be able to
- // do better.
- //
- // We can't TBZ the poison bit because EnhancedPAC2 XORs the PAC bits
- // on failure.
- // We can't TST the PAC bits because we don't always know how the address
- // space is setup for the target environment (and the bottom PAC bit is
- // based on that).
- // Either way, we also don't always know whether TBI is enabled or not for
- // the specific target environment.
+ // See the documentation on AuthCheckMethod enumeration constants for
+ // the specific code sequences that can be used to perform the check.
+ using AArch64PAuth::AuthCheckMethod;
- unsigned XPACOpc = getXPACOpcodeForKey(Key);
+ if (Method == AuthCheckMethod::None)
+return;
+ if (Method == AuthCheckMethod::DummyLoad) {
+EmitToStreamer(MCInstBuilder(AArch64::LDRWui)
+ .addReg(getWRegFromXReg(ScratchReg))
+ .addReg(TestedReg)
+ .addImm(0));
+assert(ShouldTrap && !OnFailure && "DummyLoad always traps on error");
+return;
+ }
MCSymbol *SuccessSym = createTempSymbol("auth_success_");
+ if (Method == AuthCheckMethod::XPAC || Method == AuthCheckMethod::XPACHint) {
+// mov Xscratch, Xtested
+emitMovXReg(ScratchReg, TestedReg);
- // mov Xscratch, Xtested
- emitMovXReg(ScratchReg, TestedReg);
-
- // xpac(i|d) Xscratch
- EmitToStreamer(MCInstBuilder(XPACOpc).addReg(ScratchReg).addReg(ScratchReg));
+if (Method == AuthCheckMethod::XPAC) {
+ // xpac(i|d) Xscratch
+ unsigned XPA
[llvm-branch-commits] [llvm] [AArch64][PAC] Move emission of LR checks in tail calls to AsmPrinter (PR #110705)
https://github.com/atrosinenko ready_for_review https://github.com/llvm/llvm-project/pull/110705 ___ 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] [AArch64][PAC] Move emission of LR checks in tail calls to AsmPrinter (PR #110705)
llvmbot wrote:
@llvm/pr-subscribers-backend-aarch64
Author: Anatoly Trosinenko (atrosinenko)
Changes
Move the emission of the checks performed on the authenticated LR value
during tail calls to AArch64AsmPrinter class, so that different checker
sequences can be reused by pseudo instructions expanded there.
This adds one more option to AuthCheckMethod enumeration, the generic
XPAC variant which is not restricted to checking the LR register.
Shorten the generic XPAC-based non-trapping sequence by one `mov`
instruction: perform XPAC on the tested register itself instead of the
scratch one as XPACLRI cannot operate on the scratch register anyway.
---
Patch is 33.08 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/110705.diff
9 Files Affected:
- (modified) llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp (+112-31)
- (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.cpp (+13)
- (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.td (+2)
- (modified) llvm/lib/Target/AArch64/AArch64PointerAuth.cpp (+2-180)
- (modified) llvm/lib/Target/AArch64/AArch64PointerAuth.h (+18-22)
- (modified) llvm/lib/Target/AArch64/AArch64Subtarget.cpp (-2)
- (modified) llvm/lib/Target/AArch64/AArch64Subtarget.h (-23)
- (modified) llvm/test/CodeGen/AArch64/ptrauth-ret-trap.ll (+18-18)
- (modified) llvm/test/CodeGen/AArch64/sign-return-address-tailcall.ll (+27-27)
``diff
diff --git a/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
b/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
index 6d2dd0ecbccf31..50502477706ccf 100644
--- a/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ b/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -153,6 +153,7 @@ class AArch64AsmPrinter : public AsmPrinter {
void emitPtrauthCheckAuthenticatedValue(Register TestedReg,
Register ScratchReg,
AArch64PACKey::ID Key,
+ AArch64PAuth::AuthCheckMethod Method,
bool ShouldTrap,
const MCSymbol *OnFailure);
@@ -1731,7 +1732,8 @@ unsigned
AArch64AsmPrinter::emitPtrauthDiscriminator(uint16_t Disc,
/// of proceeding to the next instruction (only if ShouldTrap is false).
void AArch64AsmPrinter::emitPtrauthCheckAuthenticatedValue(
Register TestedReg, Register ScratchReg, AArch64PACKey::ID Key,
-bool ShouldTrap, const MCSymbol *OnFailure) {
+AArch64PAuth::AuthCheckMethod Method, bool ShouldTrap,
+const MCSymbol *OnFailure) {
// Insert a sequence to check if authentication of TestedReg succeeded,
// such as:
//
@@ -1757,38 +1759,70 @@ void
AArch64AsmPrinter::emitPtrauthCheckAuthenticatedValue(
//Lsuccess:
// ...
//
- // This sequence is expensive, but we need more information to be able to
- // do better.
- //
- // We can't TBZ the poison bit because EnhancedPAC2 XORs the PAC bits
- // on failure.
- // We can't TST the PAC bits because we don't always know how the address
- // space is setup for the target environment (and the bottom PAC bit is
- // based on that).
- // Either way, we also don't always know whether TBI is enabled or not for
- // the specific target environment.
+ // See the documentation on AuthCheckMethod enumeration constants for
+ // the specific code sequences that can be used to perform the check.
+ using AArch64PAuth::AuthCheckMethod;
- unsigned XPACOpc = getXPACOpcodeForKey(Key);
+ if (Method == AuthCheckMethod::None)
+return;
+ if (Method == AuthCheckMethod::DummyLoad) {
+EmitToStreamer(MCInstBuilder(AArch64::LDRWui)
+ .addReg(getWRegFromXReg(ScratchReg))
+ .addReg(TestedReg)
+ .addImm(0));
+assert(ShouldTrap && !OnFailure && "DummyLoad always traps on error");
+return;
+ }
MCSymbol *SuccessSym = createTempSymbol("auth_success_");
+ if (Method == AuthCheckMethod::XPAC || Method == AuthCheckMethod::XPACHint) {
+// mov Xscratch, Xtested
+emitMovXReg(ScratchReg, TestedReg);
- // mov Xscratch, Xtested
- emitMovXReg(ScratchReg, TestedReg);
-
- // xpac(i|d) Xscratch
- EmitToStreamer(MCInstBuilder(XPACOpc).addReg(ScratchReg).addReg(ScratchReg));
+if (Method == AuthCheckMethod::XPAC) {
+ // xpac(i|d) Xscratch
+ unsigned XPACOpc = getXPACOpcodeForKey(Key);
+ EmitToStreamer(
+ MCInstBuilder(XPACOpc).addReg(ScratchReg).addReg(ScratchReg));
+} else {
+ // xpaclri
+
+ // Note that this method applies XPAC to TestedReg instead of ScratchReg.
+ assert(TestedReg == AArch64::LR &&
+ "XPACHint mode is only compatible with checking the LR register");
+ assert((Key == AArch64PACKey::IA || Key == AArch64PACKey::IB) &&
+ "XPACHint mode is only compatible with I-keys");
+ EmitToStreamer(MCInstBuilder(AArch64::XPACLRI));
+}
- // cmp
[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
2216bfe4a07625d894accf5730a313a65d30a982...c7bc5e9785751bba5784b2ec93702b8e5005974d
FortranRuntime/test/NonGtestUnit/lit.cfg.py
FortranRuntime/test/Unit/lit.cfg.py FortranRuntime/test/lit.cfg.py
flang/test/lit.cfg.py
``
View the diff from darker here.
``diff
--- FortranRuntime/test/lit.cfg.py 2024-10-01 13:43:59.00 +
+++ FortranRuntime/test/lit.cfg.py 2024-10-01 13:48:33.086896 +
@@ -50,37 +50,35 @@
llvm_config.use_default_substitutions()
# test_source_root: The root path where tests are located.
config.test_source_root = os.path.dirname(__file__)
-# test_exec_root: The root path where tests should be run.
+# test_exec_root: The root path where tests should be run.
# lit writes a '.lit_test_times.txt' file into this directory.
config.test_exec_root = config.fortranruntime_binary_test_dir
# On MacOS, -isysroot is needed to build binaries.
isysroot_flag = []
if config.osx_sysroot:
isysroot_flag = ["-isysroot", config.osx_sysroot]
tools = [
- ToolSubst(
+ToolSubst(
"%flang",
command=FindTool("flang-new"),
extra_args=isysroot_flag,
unresolved="fatal",
- )
-]
+)
+]
# Define some variables to help us test that the flang runtime doesn't depend
on
# the C++ runtime libraries. For this we need a C compiler.
libruntime = os.path.join(config.fortranruntime_build_lib_dir,
"libFortranRuntime.a")
include = os.path.join(config.fortranruntime_source_dir, "include")
tools.append(
-ToolSubst(
-"%cc", command=config.cc, extra_args=isysroot_flag,
unresolved="fatal"
-)
-)
+ToolSubst("%cc", command=config.cc, extra_args=isysroot_flag,
unresolved="fatal")
+)
tools.append(ToolSubst("%libruntime", command=libruntime, unresolved="fatal"))
tools.append(ToolSubst("%include", command=include, unresolved="fatal"))
# Lwt tests find LLVM's standard tools (FileCheck, split-file, not, ...)
llvm_config.with_environment("PATH", config.llvm_tools_dir, append_path=True)
``
https://github.com/llvm/llvm-project/pull/110217
___
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] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
ldionne wrote: As I explained in the original PR, I think this is a fairly important fix since that was an unintentional change in LLVM 19, but this can also potentially break people who compiled with LLVM 19.1. Since we're making the fix on `main`, it will land in LLVM 20 anyway and I think it's best to land sooner rather than later, but I'll let the release manager decide. @tru If you need additional context or information about this change, feel free to ping me on Discord and we could even set up a quick chat. https://github.com/llvm/llvm-project/pull/110677 ___ 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/19.x: workflow/release-binaries: Checkout sources before downloading artifacts (#109349) (PR #110664)
llvmbot wrote: @tru What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/110664 ___ 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] d401987 - [X86][APX] Do not emit {evex} prefix for memory variant (#109759)
Author: Phoebe Wang
Date: 2024-10-01T14:08:12+02:00
New Revision: d401987fe349a87c53fe25829215b080b70c0c1a
URL:
https://github.com/llvm/llvm-project/commit/d401987fe349a87c53fe25829215b080b70c0c1a
DIFF:
https://github.com/llvm/llvm-project/commit/d401987fe349a87c53fe25829215b080b70c0c1a.diff
LOG: [X86][APX] Do not emit {evex} prefix for memory variant (#109759)
This was mistakely changed by #109579, which doesn't match with other
EVEX decoding.
(cherry picked from commit 70529b24a30943d46e361d2990268499921e28a2)
Added:
Modified:
llvm/lib/Target/X86/X86InstrAVX512.td
llvm/test/MC/Disassembler/X86/apx/kmov.txt
Removed:
diff --git a/llvm/lib/Target/X86/X86InstrAVX512.td
b/llvm/lib/Target/X86/X86InstrAVX512.td
index 1bf201f2bb87e4..cc1f9090c11acc 100644
--- a/llvm/lib/Target/X86/X86InstrAVX512.td
+++ b/llvm/lib/Target/X86/X86InstrAVX512.td
@@ -2617,20 +2617,19 @@ defm VFPCLASS : avx512_fp_fpclass_all<"vfpclass", 0x66,
0x67, SchedWriteFCmp>, E
multiclass avx512_mask_mov opc_kk, bits<8> opc_km, bits<8> opc_mk,
string OpcodeStr, RegisterClass KRC, ValueType vvt,
X86MemOperand x86memop, string Suffix = ""> {
- let explicitOpPrefix = !if(!eq(Suffix, ""), NoExplicitOpPrefix,
ExplicitEVEX) in {
-let isMoveReg = 1, hasSideEffects = 0, SchedRW = [WriteMove] in
-def kk#Suffix : I,
-Sched<[WriteMove]>;
-def km#Suffix : I,
-Sched<[WriteLoad]>, NoCD8;
-def mk#Suffix : I,
-Sched<[WriteStore]>, NoCD8;
- }
+ let isMoveReg = 1, hasSideEffects = 0, SchedRW = [WriteMove],
+ explicitOpPrefix = !if(!eq(Suffix, ""), NoExplicitOpPrefix,
ExplicitEVEX) in
+ def kk#Suffix : I,
+ Sched<[WriteMove]>;
+ def km#Suffix : I,
+ Sched<[WriteLoad]>, NoCD8;
+ def mk#Suffix : I,
+ Sched<[WriteStore]>, NoCD8;
}
multiclass avx512_mask_mov_gpr opc_kr, bits<8> opc_rk,
diff --git a/llvm/test/MC/Disassembler/X86/apx/kmov.txt
b/llvm/test/MC/Disassembler/X86/apx/kmov.txt
index 45fedbd0da587b..ba77dda64e59f5 100644
--- a/llvm/test/MC/Disassembler/X86/apx/kmov.txt
+++ b/llvm/test/MC/Disassembler/X86/apx/kmov.txt
@@ -17,20 +17,20 @@
# INTEL: {evex} kmovq k2, k1
0x62,0xf1,0xfc,0x08,0x90,0xd1
-# ATT: {evex} kmovb -16(%rax), %k0
-# INTEL: {evex} kmovb k0, byte ptr [rax - 16]
+# ATT: kmovb -16(%rax), %k0
+# INTEL: kmovb k0, byte ptr [rax - 16]
0x62,0xf1,0x7d,0x08,0x90,0x40,0xf0
-# ATT: {evex} kmovw -16(%rax), %k0
-# INTEL: {evex} kmovw k0, word ptr [rax - 16]
+# ATT: kmovw -16(%rax), %k0
+# INTEL: kmovw k0, word ptr [rax - 16]
0x62,0xf1,0x7c,0x08,0x90,0x40,0xf0
-# ATT: {evex} kmovd -16(%rax), %k0
-# INTEL: {evex} kmovd k0, dword ptr [rax - 16]
+# ATT: kmovd -16(%rax), %k0
+# INTEL: kmovd k0, dword ptr [rax - 16]
0x62,0xf1,0xfd,0x08,0x90,0x40,0xf0
-# ATT: {evex} kmovq -16(%rax), %k0
-# INTEL: {evex} kmovq k0, qword ptr [rax - 16]
+# ATT: kmovq -16(%rax), %k0
+# INTEL: kmovq k0, qword ptr [rax - 16]
0x62,0xf1,0xfc,0x08,0x90,0x40,0xf0
# ATT-NOT: {evex}
___
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/19.x: workflow/release-binaries: Checkout sources before downloading artifacts (#109349) (PR #110664)
llvmbot wrote:
@llvm/pr-subscribers-github-workflow
Author: None (llvmbot)
Changes
Backport 8f2aa9dbad7c1400f66e1ee1c43b071a1905f3e6
Requested by: @tstellar
---
Full diff: https://github.com/llvm/llvm-project/pull/110664.diff
1 Files Affected:
- (modified) .github/workflows/release-binaries.yml (+8-8)
``diff
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 925912df6843e4..f24e25879b96bd 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -420,6 +420,14 @@ jobs:
attestations: write # For artifact attestations
steps:
+- name: Checkout Release Scripts
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+ with:
+sparse-checkout: |
+ llvm/utils/release/github-upload-release.py
+ llvm/utils/git/requirements.txt
+sparse-checkout-cone-mode: false
+
- name: 'Download artifact'
uses: actions/download-artifact@6b208ae046db98c579e8a3aa621ab581ff575935
# v4.1.1
with:
@@ -442,14 +450,6 @@ jobs:
name: ${{ needs.prepare.outputs.release-binary-filename }}-attestation
path: ${{ needs.prepare.outputs.release-binary-filename }}.jsonl
-- name: Checkout Release Scripts
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- with:
-sparse-checkout: |
- llvm/utils/release/github-upload-release.py
- llvm/utils/git/requirements.txt
-sparse-checkout-cone-mode: false
-
- name: Install Python Requirements
run: |
pip install --require-hashes -r ./llvm/utils/git/requirements.txt
``
https://github.com/llvm/llvm-project/pull/110664
___
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] 1f681b5 - [CodeGen] Clear InitUndef pass new register cache between pass runs (#90967)
Author: Joe Faulls
Date: 2024-10-01T13:49:40+02:00
New Revision: 1f681b5913f9169332e4126ac0aafeedc5ca6cef
URL:
https://github.com/llvm/llvm-project/commit/1f681b5913f9169332e4126ac0aafeedc5ca6cef
DIFF:
https://github.com/llvm/llvm-project/commit/1f681b5913f9169332e4126ac0aafeedc5ca6cef.diff
LOG: [CodeGen] Clear InitUndef pass new register cache between pass runs
(#90967)
Multiple invocations of the pass could interfere with eachother,
preventing some undefs being initialised.
I found it very difficult to create a unit test for this due to it being
dependent on particular allocations of a previous function. However, the
bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the
creation of the illegal instruction `vnsrl.wi v9, v8, 0`
Added:
Modified:
llvm/lib/CodeGen/InitUndef.cpp
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
llvm/test/CodeGen/RISCV/rvv/shuffle-reverse.ll
Removed:
diff --git a/llvm/lib/CodeGen/InitUndef.cpp b/llvm/lib/CodeGen/InitUndef.cpp
index 51c50ff872ef21..8f25ede0eb2b7e 100644
--- a/llvm/lib/CodeGen/InitUndef.cpp
+++ b/llvm/lib/CodeGen/InitUndef.cpp
@@ -272,6 +272,7 @@ bool InitUndef::runOnMachineFunction(MachineFunction &MF) {
for (auto *DeadMI : DeadInsts)
DeadMI->eraseFromParent();
DeadInsts.clear();
+ NewRegs.clear();
return Changed;
}
diff --git a/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
b/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
index 65a1035fd815c0..5d75efe681af73 100644
--- a/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
+++ b/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
@@ -567,16 +567,15 @@ define <8 x i32> @add_constant_rhs_8xi32_partial(<8 x
i32> %vin, i32 %a, i32 %b,
; CHECK-NEXT:vsetivli zero, 6, e32, m2, tu, ma
; CHECK-NEXT:vslideup.vi v8, v10, 5
; CHECK-NEXT:vmv.s.x v10, a2
-; CHECK-NEXT:lui a0, %hi(.LCPI19_0)
-; CHECK-NEXT:addi a0, a0, %lo(.LCPI19_0)
-; CHECK-NEXT:vsetivli zero, 8, e32, m2, ta, ma
-; CHECK-NEXT:vle32.v v12, (a0)
; CHECK-NEXT:vsetivli zero, 7, e32, m2, tu, ma
; CHECK-NEXT:vslideup.vi v8, v10, 6
-; CHECK-NEXT:vmv.s.x v10, a3
+; CHECK-NEXT:lui a0, %hi(.LCPI19_0)
+; CHECK-NEXT:addi a0, a0, %lo(.LCPI19_0)
; CHECK-NEXT:vsetivli zero, 8, e32, m2, ta, ma
-; CHECK-NEXT:vslideup.vi v8, v10, 7
-; CHECK-NEXT:vadd.vv v8, v8, v12
+; CHECK-NEXT:vle32.v v10, (a0)
+; CHECK-NEXT:vmv.s.x v12, a3
+; CHECK-NEXT:vslideup.vi v8, v12, 7
+; CHECK-NEXT:vadd.vv v8, v8, v10
; CHECK-NEXT:ret
%vadd = add <8 x i32> %vin,
%e0 = add i32 %a, 23
diff --git a/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
b/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
index 14f4f44049c533..24a5bd154c64f5 100644
--- a/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
+++ b/llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
@@ -2501,9 +2501,9 @@ define <8 x i32> @mgather_baseidx_v8i8_v8i32(ptr %base,
<8 x i8> %idxs, <8 x i1>
; RV64ZVE32F-NEXT:add a2, a0, a2
; RV64ZVE32F-NEXT:lw a2, 0(a2)
; RV64ZVE32F-NEXT:vsetvli zero, zero, e32, m1, ta, ma
-; RV64ZVE32F-NEXT:vmv.s.x v8, a2
+; RV64ZVE32F-NEXT:vmv.s.x v12, a2
; RV64ZVE32F-NEXT:vsetivli zero, 6, e32, m2, tu, ma
-; RV64ZVE32F-NEXT:vslideup.vi v10, v8, 5
+; RV64ZVE32F-NEXT:vslideup.vi v10, v12, 5
; RV64ZVE32F-NEXT: .LBB35_9: # %else14
; RV64ZVE32F-NEXT:andi a2, a1, 64
; RV64ZVE32F-NEXT:vsetivli zero, 2, e8, mf4, ta, ma
@@ -2546,9 +2546,9 @@ define <8 x i32> @mgather_baseidx_v8i8_v8i32(ptr %base,
<8 x i8> %idxs, <8 x i1>
; RV64ZVE32F-NEXT:add a2, a0, a2
; RV64ZVE32F-NEXT:lw a2, 0(a2)
; RV64ZVE32F-NEXT:vsetvli zero, zero, e32, m4, ta, ma
-; RV64ZVE32F-NEXT:vmv.s.x v8, a2
+; RV64ZVE32F-NEXT:vmv.s.x v12, a2
; RV64ZVE32F-NEXT:vsetivli zero, 5, e32, m2, tu, ma
-; RV64ZVE32F-NEXT:vslideup.vi v10, v8, 4
+; RV64ZVE32F-NEXT:vslideup.vi v10, v12, 4
; RV64ZVE32F-NEXT:andi a2, a1, 32
; RV64ZVE32F-NEXT:bnez a2, .LBB35_8
; RV64ZVE32F-NEXT:j .LBB35_9
@@ -2652,9 +2652,9 @@ define <8 x i32> @mgather_baseidx_sext_v8i8_v8i32(ptr
%base, <8 x i8> %idxs, <8
; RV64ZVE32F-NEXT:add a2, a0, a2
; RV64ZVE32F-NEXT:lw a2, 0(a2)
; RV64ZVE32F-NEXT:vsetvli zero, zero, e32, m1, ta, ma
-; RV64ZVE32F-NEXT:vmv.s.x v8, a2
+; RV64ZVE32F-NEXT:vmv.s.x v12, a2
; RV64ZVE32F-NEXT:vsetivli zero, 6, e32, m2, tu, ma
-; RV64ZVE32F-NEXT:vslideup.vi v10, v8, 5
+; RV64ZVE32F-NEXT:vslideup.vi v10, v12, 5
; RV64ZVE32F-NEXT: .LBB36_9: # %else14
; RV64ZVE32F-NEXT:andi a2, a1, 64
; RV64ZVE32F-NEXT:vsetivli zero, 2, e8, mf4, ta, ma
@@ -2697,9 +2697,9 @@ define <8 x i32> @mgather_baseidx_sext_v8i8_v8i32(ptr
%base, <8 x i8> %idxs
[llvm-branch-commits] [mlir] [MLIR][OpenMP] Document entry block argument-defining clauses (NFC) (PR #109811)
bhandarkar-pranav wrote: > Thanks for the feedback Pranav, let me know if the changes address your > concerns. Thank you for the changes. This LGTM. https://github.com/llvm/llvm-project/pull/109811 ___ 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] 23eadbd - [libcxx][test] Use smaller time range for 32 bit time_t (#104762)
Author: David Spickett
Date: 2024-10-01T09:03:25+02:00
New Revision: 23eadbda36887257fcc197fef6f71ddc1830b8ab
URL:
https://github.com/llvm/llvm-project/commit/23eadbda36887257fcc197fef6f71ddc1830b8ab
DIFF:
https://github.com/llvm/llvm-project/commit/23eadbda36887257fcc197fef6f71ddc1830b8ab.diff
LOG: [libcxx][test] Use smaller time range for 32 bit time_t (#104762)
This fixes the test on Arm 32 bit Ubuntu Jammy where time_t is 32 bit.
(cherry picked from commit cdd608b8f0ce090b3568238387df368751bdbb5d)
Added:
Modified:
libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
Removed:
diff --git
a/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
b/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
index 2b97d9a5bc745b..b474fe50083b1d 100644
---
a/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
+++
b/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
@@ -13,9 +13,6 @@
// XFAIL: libcpp-has-no-experimental-tzdb
// XFAIL: availability-tzdb-missing
-// TODO TZDB Investigate
-// UNSUPPORTED: target={{armv(7|8)l-linux-gnueabihf}}
-
#include
#include
#include
@@ -28,7 +25,7 @@
// The year range to validate. The dates used in practice are expected to be
// inside the tested range.
constexpr std::chrono::year first{1800};
-constexpr std::chrono::year last{2100};
+constexpr std::chrono::year last{sizeof(time_t) == 8 ? 2100 : 2037};
// A custom sys_info class that also stores the name of the time zone.
// Its formatter matches the output of zdump.
___
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] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/110217 ___ 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] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
Meinersbur wrote: I reverted the change that moved `flang/module/*.f90` to `FortranRuntime/module/*.f90`. A lot of Flang tests depend on the `*.mod` files to be available. Moving the modules to FortranRuntime would require moving those tests to FortranRuntime as well to avoid a circular dependency. Except the PPC modules, the mod files are not target-specific and hence would not profit from compiling multiple targets from a bootstrap build anyway. However, they are products of the Flang compiler and therefore IMHO logically fits better to the runtime. Also, it would have been nice to make use of CMake's dependency resolution than hardcoding Into the CMakeLists.txt. In any case, such a change can be applied later. https://github.com/llvm/llvm-project/pull/110217 ___ 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/19.x: Fix libFuzzer not building with pthreads on Windows (#109525) (PR #110663)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/110663 ___ 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/19.x: Fix libFuzzer not building with pthreads on Windows (#109525) (PR #110663)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/110663
Backport b4130bee6bfd34d8045f02fc9f951bcb5db9d85c
Requested by: @mstorsjo
>From 35d177578d70c70b38ea9d6cf7a5cceec86291e3 Mon Sep 17 00:00:00 2001
From: Zentrik
Date: Tue, 24 Sep 2024 21:33:57 +0100
Subject: [PATCH] Fix libFuzzer not building with pthreads on Windows (#109525)
Fixes https://github.com/llvm/llvm-project/issues/106871
(cherry picked from commit b4130bee6bfd34d8045f02fc9f951bcb5db9d85c)
---
compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp | 5 +
1 file changed, 5 insertions(+)
diff --git a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
index db80eb383885e6..73eea07cf869ff 100644
--- a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
+++ b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
@@ -239,6 +239,10 @@ size_t PageSize() {
}
void SetThreadName(std::thread &thread, const std::string &name) {
+#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) ||
\
+defined(_GLIBCXX_GCC_GTHR_POSIX_H)
+ (void)pthread_setname_np(thread.native_handle(), name.c_str());
+#else
typedef HRESULT(WINAPI * proc)(HANDLE, PCWSTR);
HMODULE kbase = GetModuleHandleA("KernelBase.dll");
proc ThreadNameProc =
@@ -253,6 +257,7 @@ void SetThreadName(std::thread &thread, const std::string
&name) {
}
}
}
+#endif
}
} // namespace fuzzer
___
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] 4dbe72f - [lldb][test] Mark sys_info zdump test unsupported on 32 bit Arm Linux
Author: David Spickett
Date: 2024-10-01T09:03:25+02:00
New Revision: 4dbe72f91a9601e66db2bee59c5bebcdc63f9472
URL:
https://github.com/llvm/llvm-project/commit/4dbe72f91a9601e66db2bee59c5bebcdc63f9472
DIFF:
https://github.com/llvm/llvm-project/commit/4dbe72f91a9601e66db2bee59c5bebcdc63f9472.diff
LOG: [lldb][test] Mark sys_info zdump test unsupported on 32 bit Arm Linux
Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.
This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.
Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.
(cherry picked from commit 6f6422f4a2b8647a59936c131e50a79906d89510)
Added:
Modified:
libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
Removed:
diff --git
a/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
b/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
index 207f8e4df45413..2b97d9a5bc745b 100644
---
a/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
+++
b/libcxx/test/std/time/time.zone/time.zone.timezone/time.zone.members/sys_info.zdump.pass.cpp
@@ -14,7 +14,7 @@
// XFAIL: availability-tzdb-missing
// TODO TZDB Investigate
-// XFAIL: target={{armv(7|8)l-linux-gnueabihf}}
+// UNSUPPORTED: target={{armv(7|8)l-linux-gnueabihf}}
#include
#include
___
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] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
https://github.com/Meinersbur edited https://github.com/llvm/llvm-project/pull/110217 ___ 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] 600a105 - Revert "Add missing extendhfxf2 in compiler rt (#109090)"
Author: lntue
Date: 2024-10-01T08:59:41-04:00
New Revision: 600a105c09ef0479fa9307112e9dda7f4212dbb7
URL:
https://github.com/llvm/llvm-project/commit/600a105c09ef0479fa9307112e9dda7f4212dbb7
DIFF:
https://github.com/llvm/llvm-project/commit/600a105c09ef0479fa9307112e9dda7f4212dbb7.diff
LOG: Revert "Add missing extendhfxf2 in compiler rt (#109090)"
This reverts commit a57a83fc15219184ea45fc026b917888088d43f2.
Added:
Modified:
compiler-rt/lib/builtins/CMakeLists.txt
compiler-rt/lib/builtins/macho_embedded/common.txt
llvm/utils/gn/secondary/compiler-rt/lib/builtins/BUILD.gn
Removed:
compiler-rt/lib/builtins/extendhfxf2.c
compiler-rt/test/builtins/Unit/extendhfxf2_test.c
diff --git a/compiler-rt/lib/builtins/CMakeLists.txt
b/compiler-rt/lib/builtins/CMakeLists.txt
index 97a9e508d37a32..9a0a50ee7003f1 100644
--- a/compiler-rt/lib/builtins/CMakeLists.txt
+++ b/compiler-rt/lib/builtins/CMakeLists.txt
@@ -104,7 +104,6 @@ set(GENERIC_SOURCES
divti3.c
extendsfdf2.c
extendhfsf2.c
- extendhfxf2.c
ffsdi2.c
ffssi2.c
ffsti2.c
diff --git a/compiler-rt/lib/builtins/extendhfxf2.c
b/compiler-rt/lib/builtins/extendhfxf2.c
deleted file mode 100644
index 7425859f79f763..00
--- a/compiler-rt/lib/builtins/extendhfxf2.c
+++ /dev/null
@@ -1,18 +0,0 @@
-//===-- lib/extendhfxf2.c - half -> long double conversion *- C
-*-===//
-//
-// 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
-//
-//===--===//
-
-#define SRC_HALF
-#define DST_DOUBLE
-#include "fp_extend_impl.inc"
-
-// Use a forwarding definition and noinline to implement a poor man's alias,
-// as there isn't a good cross-platform way of defining one.
-// Long double are expected to be as precise as double.
-COMPILER_RT_ABI NOINLINE long double __extendhfxf2(src_t a) {
- return (long double)__extendXfYf2__(a);
-}
diff --git a/compiler-rt/lib/builtins/macho_embedded/common.txt
b/compiler-rt/lib/builtins/macho_embedded/common.txt
index fa99bc239e68f2..819109768f5298 100644
--- a/compiler-rt/lib/builtins/macho_embedded/common.txt
+++ b/compiler-rt/lib/builtins/macho_embedded/common.txt
@@ -60,7 +60,6 @@ divsf3
divsi3
extendsfdf2
extendhfsf2
-extendhfxf2
ffssi2
fixdfsi
fixsfsi
diff --git a/compiler-rt/test/builtins/Unit/extendhfxf2_test.c
b/compiler-rt/test/builtins/Unit/extendhfxf2_test.c
deleted file mode 100644
index 59d11eeff0ce5a..00
--- a/compiler-rt/test/builtins/Unit/extendhfxf2_test.c
+++ /dev/null
@@ -1,61 +0,0 @@
-// RUN: %clang_builtins %s %librt -o %t && %run %t
-// REQUIRES: librt_has_extendhfxf2
-
-#include
-#include // for isnan, isinf
-#include
-
-long double __extendhfxf2(_Float16 f);
-
-int test_extendhfxf2(_Float16 a, long double expected) {
- long double x = __extendhfxf2(a);
- __uint16_t *b = (void *)&a;
- int ret = !(x == expected || (isnan(x) && isnan(expected)) ||
- (isinf(x) && isinf(expected) && x == expected));
- if (ret) {
-printf("error in test__extendhfsf2(%#.4x) = %.20Lf, "
- "expected %.20Lf\n",
- *b, x, expected);
- }
- return ret;
-}
-
-char assumption_1[sizeof(_Float16) * CHAR_BIT == 16] = {0};
-
-int main() {
- // Small positive value
- if (test_extendhfxf2(0.0999755859375000f, 0.0999755859375000L))
-return 1;
-
- // Small negative value
- if (test_extendhfxf2(-0.0999755859375000f, -0.0999755859375000L))
-return 1;
-
- // Zero
- if (test_extendhfxf2(0.0f, 0.0L))
-return 1;
-
- // Smallest positive non-zero value
- if (test_extendhfxf2(0x1p-16f, 0x1p-16L))
-return 1;
-
- // Smallest negative non-zero value
- if (test_extendhfxf2(-0x1p-16f, -0x1p-16L))
-return 1;
-
- // Positive infinity
- if (test_extendhfxf2(__builtin_huge_valf16(), __builtin_huge_valf64x()))
-return 1;
-
- // Negative infinity
- if (test_extendhfxf2(-__builtin_huge_valf16(),
- (long double)-__builtin_huge_valf64x()))
-return 1;
-
- // NaN
- if (test_extendhfxf2(__builtin_nanf16(""),
- (long double)__builtin_nanf64x("")))
-return 1;
-
- return 0;
-}
diff --git a/llvm/utils/gn/secondary/compiler-rt/lib/builtins/BUILD.gn
b/llvm/utils/gn/secondary/compiler-rt/lib/builtins/BUILD.gn
index efbf01960bf907..8904aed28229f1 100644
--- a/llvm/utils/gn/secondary/compiler-rt/lib/builtins/BUILD.gn
+++ b/llvm/utils/gn/secondary/compiler-rt/lib/builtins/BUILD.gn
@@ -126,7 +126,6 @@ static_library("builtins") {
"divsi3.c",
"divti3.c",
"extendhfsf2.c",
-"extendhfxf2.c"
"extendsfdf2.c",
"ffsdi2.c",
"ffssi2.c",
___
llvm-branch-commits mailing list
llvm-
[llvm-branch-commits] [flang] [Flang][OpenMP] Improve entry block argument creation and binding (PR #110267)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110267
>From efa0c3271ece41ee04e6d34fa83021ded72d4c47 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 27 Sep 2024 13:51:27 +0100
Subject: [PATCH] [Flang][OpenMP] Improve entry block argument creation and
binding
The main purpose of this patch is to centralize the logic for creating MLIR
operation entry blocks and for binding them to the corresponding symbols. This
minimizes the chances of mixing arguments up for operations having multiple
entry block argument-generating clauses and prevents divergence while binding
arguments.
Some changes implemented to this end are:
- Split into two functions the creation of the entry block, and the binding of
its arguments and the corresponding Fortran symbol. This enabled a significant
simplification of the lowering of composite constructs, where it's no longer
necessary to manually ensure the lists of arguments and symbols refer to the
same variables in the same order and also match the expected order by the
`BlockArgOpenMPOpInterface`.
- Removed redundant and error-prone passing of types and locations from
`ClauseProcessor` methods. Instead, these are obtained from the values in the
appropriate clause operands structure. This also simplifies argument lists of
several lowering functions.
- Access block arguments of already created MLIR operations through the
`BlockArgOpenMPOpInterface` instead of directly indexing the argument list of
the operation, which is not scalable as more entry block argument-generating
clauses are added to an operation.
- Simplified the implementation of `genParallelOp` to no longer need to define
different callbacks depending on whether delayed privatization is enabled.
---
flang/lib/Lower/OpenMP/ClauseProcessor.cpp| 79 +-
flang/lib/Lower/OpenMP/ClauseProcessor.h | 38 +-
flang/lib/Lower/OpenMP/OpenMP.cpp | 1022 +
flang/lib/Lower/OpenMP/ReductionProcessor.cpp |5 +-
flang/lib/Lower/OpenMP/ReductionProcessor.h |3 +-
flang/lib/Lower/OpenMP/Utils.cpp |9 +-
flang/lib/Lower/OpenMP/Utils.h|4 +-
7 files changed, 560 insertions(+), 600 deletions(-)
diff --git a/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
b/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
index e9ef8579100e93..44f5ca7f342707 100644
--- a/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
+++ b/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
@@ -166,15 +166,11 @@ getIfClauseOperand(lower::AbstractConverter &converter,
static void addUseDeviceClause(
lower::AbstractConverter &converter, const omp::ObjectList &objects,
llvm::SmallVectorImpl &operands,
-llvm::SmallVectorImpl &useDeviceTypes,
-llvm::SmallVectorImpl &useDeviceLocs,
llvm::SmallVectorImpl &useDeviceSyms) {
genObjectList(objects, converter, operands);
- for (mlir::Value &operand : operands) {
+ for (mlir::Value &operand : operands)
checkMapType(operand.getLoc(), operand.getType());
-useDeviceTypes.push_back(operand.getType());
-useDeviceLocs.push_back(operand.getLoc());
- }
+
for (const omp::Object &object : objects)
useDeviceSyms.push_back(object.sym());
}
@@ -832,14 +828,12 @@ bool
ClauseProcessor::processDepend(mlir::omp::DependClauseOps &result) const {
bool ClauseProcessor::processHasDeviceAddr(
mlir::omp::HasDeviceAddrClauseOps &result,
-llvm::SmallVectorImpl &isDeviceTypes,
-llvm::SmallVectorImpl &isDeviceLocs,
-llvm::SmallVectorImpl &isDeviceSymbols) const {
+llvm::SmallVectorImpl &isDeviceSyms) const {
return findRepeatableClause(
[&](const omp::clause::HasDeviceAddr &devAddrClause,
const parser::CharBlock &) {
addUseDeviceClause(converter, devAddrClause.v,
result.hasDeviceAddrVars,
- isDeviceTypes, isDeviceLocs, isDeviceSymbols);
+ isDeviceSyms);
});
}
@@ -864,14 +858,12 @@ bool ClauseProcessor::processIf(
bool ClauseProcessor::processIsDevicePtr(
mlir::omp::IsDevicePtrClauseOps &result,
-llvm::SmallVectorImpl &isDeviceTypes,
-llvm::SmallVectorImpl &isDeviceLocs,
-llvm::SmallVectorImpl &isDeviceSymbols) const {
+llvm::SmallVectorImpl &isDeviceSyms) const {
return findRepeatableClause(
[&](const omp::clause::IsDevicePtr &devPtrClause,
const parser::CharBlock &) {
addUseDeviceClause(converter, devPtrClause.v, result.isDevicePtrVars,
- isDeviceTypes, isDeviceLocs, isDeviceSymbols);
+ isDeviceSyms);
});
}
@@ -892,9 +884,7 @@ void ClauseProcessor::processMapObjects(
std::map> &parentMemberIndices,
llvm::SmallVectorImpl &mapVars,
-llvm::SmallVectorImpl *mapSyms,
-llvm::SmallVectorImpl *mapSymLocs,
-llvm::SmallVectorImpl *mapSymTypes) const {
+llvm::SmallVectorImpl &mapSyms) const {
fir::FirOpBuilder &firOpBuilder = converter.getFirOpBuilder();
for
[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang][DRAFT] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 2216bfe4a07625d894accf5730a313a65d30a982
c7bc5e9785751bba5784b2ec93702b8e5005974d --extensions h,c,cpp --
FortranRuntime/include/flang/Common/ISO_Fortran_binding_wrapper.h
FortranRuntime/include/flang/Runtime/io-api.h
FortranRuntime/include/flang/Runtime/iostat.h
FortranRuntime/lib/Runtime/file.cpp FortranRuntime/lib/Runtime/io-error.cpp
FortranRuntime/lib/Runtime/stat.h clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Flang.cpp flang/lib/Evaluate/fold-logical.cpp
lld/COFF/MinGW.cpp FortranRuntime/include/flang/Common/magic-numbers.h
FortranRuntime/test/Runtime/no-cpp-dep.c
flang/include/flang/ISO_Fortran_binding.h
``
View the diff from clang-format here.
``diff
diff --git a/FortranRuntime/include/flang/Common/magic-numbers.h
b/FortranRuntime/include/flang/Common/magic-numbers.h
index 931df69076..1fadc78fdf 100644
--- a/FortranRuntime/include/flang/Common/magic-numbers.h
+++ b/FortranRuntime/include/flang/Common/magic-numbers.h
@@ -1,4 +1,5 @@
-#if 0 /*===-- include/flang/Runtime/magic-numbers.h ---*- C
-*-===*/
+#if 0 /*===-- include/flang/Runtime/magic-numbers.h ---*- C \
+ -*-===*/
*
* Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
* See https://llvm.org/LICENSE.txt for license information.
diff --git a/FortranRuntime/include/flang/Runtime/io-api.h
b/FortranRuntime/include/flang/Runtime/io-api.h
index 93971a2282..be948061c2 100644
--- a/FortranRuntime/include/flang/Runtime/io-api.h
+++ b/FortranRuntime/include/flang/Runtime/io-api.h
@@ -11,10 +11,10 @@
#ifndef FORTRAN_RUNTIME_IO_API_H_
#define FORTRAN_RUNTIME_IO_API_H_
+#include "flang/Common/magic-numbers.h"
#include "flang/Common/uint128.h"
#include "flang/Runtime/entry-names.h"
#include "flang/Runtime/iostat.h"
-#include "flang/Common/magic-numbers.h"
#include
#include
diff --git a/FortranRuntime/lib/Runtime/file.cpp
b/FortranRuntime/lib/Runtime/file.cpp
index 9988ced2b5..80829d8448 100644
--- a/FortranRuntime/lib/Runtime/file.cpp
+++ b/FortranRuntime/lib/Runtime/file.cpp
@@ -7,9 +7,9 @@
//===--===//
#include "file.h"
+#include "tools.h"
#include "flang/Common/magic-numbers.h"
#include "flang/Runtime/memory.h"
-#include "tools.h"
#include
#include
#include
diff --git a/FortranRuntime/lib/Runtime/io-error.cpp
b/FortranRuntime/lib/Runtime/io-error.cpp
index 30fabe5ba0..400b211c1c 100644
--- a/FortranRuntime/lib/Runtime/io-error.cpp
+++ b/FortranRuntime/lib/Runtime/io-error.cpp
@@ -8,8 +8,8 @@
#include "io-error.h"
#include "config.h"
-#include "flang/Common/magic-numbers.h"
#include "tools.h"
+#include "flang/Common/magic-numbers.h"
#include
#include
#include
diff --git a/FortranRuntime/test/Runtime/no-cpp-dep.c
b/FortranRuntime/test/Runtime/no-cpp-dep.c
index f6760b75a1..971e714167 100644
--- a/FortranRuntime/test/Runtime/no-cpp-dep.c
+++ b/FortranRuntime/test/Runtime/no-cpp-dep.c
@@ -12,9 +12,9 @@ RUN: rm a.out
*/
#include "flang/Runtime/entry-names.h"
-#include
#include
#include
+#include
/*
Manually add declarations for the runtime functions that we want to make sure
@@ -32,8 +32,8 @@ int32_t RTNAME(ArgumentCount)();
int32_t RTNAME(GetCommandArgument)(int32_t, const struct Descriptor *,
const struct Descriptor *, const struct Descriptor *);
int32_t RTNAME(GetEnvVariable)(const struct Descriptor *,
-const struct Descriptor *, const struct Descriptor *, bool ,
-const struct Descriptor *, const char *, int );
+const struct Descriptor *, const struct Descriptor *, bool,
+const struct Descriptor *, const char *, int);
int64_t RTNAME(SystemClockCount)(int kind);
int main() {
diff --git a/flang/lib/Evaluate/fold-logical.cpp
b/flang/lib/Evaluate/fold-logical.cpp
index 3c0b85cc34..a7e1aad38f 100644
--- a/flang/lib/Evaluate/fold-logical.cpp
+++ b/flang/lib/Evaluate/fold-logical.cpp
@@ -9,8 +9,8 @@
#include "fold-implementation.h"
#include "fold-matmul.h"
#include "fold-reduction.h"
-#include "flang/Evaluate/check-expression.h"
#include "flang/Common/magic-numbers.h"
+#include "flang/Evaluate/check-expression.h"
namespace Fortran::evaluate {
``
https://github.com/llvm/llvm-project/pull/110217
___
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/19.x: [X86][APX] Fix wrong encoding of promoted KMOV instructions due to missing NoCD8 (#109759) (PR #109767)
phoebewang wrote: Thanks @tru! The title should be good as the description. https://github.com/llvm/llvm-project/pull/109767 ___ 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/19.x: workflow/release-binaries: Checkout sources before downloading artifacts (#109349) (PR #110664)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/110664
Backport 8f2aa9dbad7c1400f66e1ee1c43b071a1905f3e6
Requested by: @tstellar
>From e4d3e5993b38500718e83c0e8bfdd9ca9aa176a5 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Tue, 1 Oct 2024 06:11:15 -0700
Subject: [PATCH] workflow/release-binaries: Checkout sources before
downloading artifacts (#109349)
The actions/checkout step will clear the current directory, so we need
to checkout the sources first so that the downloaded artifacts won't be
deleted.
(cherry picked from commit 8f2aa9dbad7c1400f66e1ee1c43b071a1905f3e6)
---
.github/workflows/release-binaries.yml | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 925912df6843e4..f24e25879b96bd 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -420,6 +420,14 @@ jobs:
attestations: write # For artifact attestations
steps:
+- name: Checkout Release Scripts
+ uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+ with:
+sparse-checkout: |
+ llvm/utils/release/github-upload-release.py
+ llvm/utils/git/requirements.txt
+sparse-checkout-cone-mode: false
+
- name: 'Download artifact'
uses: actions/download-artifact@6b208ae046db98c579e8a3aa621ab581ff575935
# v4.1.1
with:
@@ -442,14 +450,6 @@ jobs:
name: ${{ needs.prepare.outputs.release-binary-filename }}-attestation
path: ${{ needs.prepare.outputs.release-binary-filename }}.jsonl
-- name: Checkout Release Scripts
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- with:
-sparse-checkout: |
- llvm/utils/release/github-upload-release.py
- llvm/utils/git/requirements.txt
-sparse-checkout-cone-mode: false
-
- name: Install Python Requirements
run: |
pip install --require-hashes -r ./llvm/utils/git/requirements.txt
___
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/19.x: workflow/release-binaries: Checkout sources before downloading artifacts (#109349) (PR #110664)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/110664 ___ 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] [mlir] [MLIR][OpenMP] Use map format to represent use_device_{addr, ptr} (PR #109810)
https://github.com/TIFitis approved this pull request. Im happy with the changes. Thanks :) https://github.com/llvm/llvm-project/pull/109810 ___ 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] [MLIR][OpenMP] Document entry block argument-defining clauses (NFC) (PR #109811)
https://github.com/bhandarkar-pranav approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/109811 ___ 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] [mlir] [MLIR][OpenMP] Use map format to represent use_device_{addr, ptr} (PR #109810)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109810
>From c08a30e2e6cdc34e9ca1fa9aebf8a42181b933b7 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 20 Sep 2024 17:11:34 +0100
Subject: [PATCH] [MLIR][OpenMP] Use map format to represent
use_device_{addr,ptr}
This patch updates the `omp.target_data` operation to use the same formatting
as `map` clauses on `omp.target` for `use_device_addr` and `use_device_ptr`.
This is done so the mapping that is being enforced between op arguments and
associated entry block arguments is explicit.
The way it is achieved is by marking these clauses as entry block
argument-defining and adjusting printer/parsers accordingly.
As a result of this change, block arguments for `use_device_addr` come before
those for `use_device_ptr`, which is the opposite of the previous undocumented
situation. Some unit tests are updated based on this change, in addition to
those updated because of the format change.
---
.../Fir/convert-to-llvm-openmp-and-fir.fir| 5 +-
flang/test/Lower/OpenMP/target.f90| 6 +-
.../use-device-ptr-to-use-device-addr.f90 | 12 +--
.../mlir/Dialect/OpenMP/OpenMPClauses.td | 28 ++-
mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td | 6 ++
.../Dialect/OpenMP/OpenMPOpsInterfaces.td | 37 -
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | 43 +++
.../OpenMP/OpenMPToLLVMIRTranslation.cpp | 77 ---
mlir/test/Dialect/OpenMP/ops.mlir | 6 +-
mlir/test/Target/LLVMIR/omptarget-llvm.mlir | 19 ++---
.../openmp-target-use-device-nested.mlir | 3 +-
11 files changed, 179 insertions(+), 63 deletions(-)
diff --git a/flang/test/Fir/convert-to-llvm-openmp-and-fir.fir
b/flang/test/Fir/convert-to-llvm-openmp-and-fir.fir
index 4d226eaa754c12..61f18008633d50 100644
--- a/flang/test/Fir/convert-to-llvm-openmp-and-fir.fir
+++ b/flang/test/Fir/convert-to-llvm-openmp-and-fir.fir
@@ -429,13 +429,14 @@ func.func @_QPopenmp_target_data_region() {
func.func @_QPomp_target_data_empty() {
%0 = fir.alloca !fir.array<1024xi32> {bindc_name = "a", uniq_name =
"_QFomp_target_data_emptyEa"}
- omp.target_data use_device_addr(%0 : !fir.ref>) {
+ omp.target_data use_device_addr(%0 -> %arg0 :
!fir.ref>) {
+omp.terminator
}
return
}
// CHECK-LABEL: llvm.func @_QPomp_target_data_empty
-// CHECK: omp.target_data use_device_addr(%1 : !llvm.ptr) {
+// CHECK: omp.target_data use_device_addr(%1 -> %{{.*}} : !llvm.ptr) {
// CHECK: }
// -
diff --git a/flang/test/Lower/OpenMP/target.f90
b/flang/test/Lower/OpenMP/target.f90
index dedce581436490..ab33b6b3808315 100644
--- a/flang/test/Lower/OpenMP/target.f90
+++ b/flang/test/Lower/OpenMP/target.f90
@@ -506,9 +506,8 @@ subroutine omp_target_device_ptr
type(c_ptr) :: a
integer, target :: b
!CHECK: %[[MAP:.*]] = omp.map.info var_ptr({{.*}}) map_clauses(tofrom)
capture(ByRef) -> {{.*}} {name = "a"}
- !CHECK: omp.target_data map_entries(%[[MAP]]{{.*}}) use_device_ptr({{.*}})
+ !CHECK: omp.target_data map_entries(%[[MAP]]{{.*}}) use_device_ptr({{.*}}
-> %[[VAL_1:.*]] :
!fir.ref>)
!$omp target data map(tofrom: a) use_device_ptr(a)
- !CHECK: ^bb0(%[[VAL_1:.*]]:
!fir.ref>):
!CHECK: {{.*}} = fir.coordinate_of %[[VAL_1:.*]], {{.*}} :
(!fir.ref>,
!fir.field) -> !fir.ref
a = c_loc(b)
!CHECK: omp.terminator
@@ -529,9 +528,8 @@ subroutine omp_target_device_addr
!CHECK: %[[MAP:.*]] = omp.map.info var_ptr({{.*}} :
!fir.ref>>, !fir.box>) map_clauses(tofrom)
capture(ByRef) members(%[[MAP_MEMBERS]] : [0] : !fir.llvm_ptr>)
-> !fir.ref>> {name = "a"}
!CHECK: %[[DEV_ADDR_MEMBERS:.*]] = omp.map.info var_ptr({{.*}} :
!fir.ref>>, i32) var_ptr_ptr({{.*}} :
!fir.llvm_ptr>) map_clauses(tofrom) capture(ByRef) ->
!fir.llvm_ptr> {name = ""}
!CHECK: %[[DEV_ADDR:.*]] = omp.map.info var_ptr({{.*}} :
!fir.ref>>, !fir.box>) map_clauses(tofrom)
capture(ByRef) members(%[[DEV_ADDR_MEMBERS]] : [0] :
!fir.llvm_ptr>) -> !fir.ref>> {name = "a"}
- !CHECK: omp.target_data map_entries(%[[MAP_MEMBERS]], %[[MAP]] : {{.*}})
use_device_addr(%[[DEV_ADDR_MEMBERS]], %[[DEV_ADDR]] : {{.*}}) {
+ !CHECK: omp.target_data map_entries(%[[MAP_MEMBERS]], %[[MAP]] : {{.*}})
use_device_addr(%[[DEV_ADDR_MEMBERS]] -> %[[ARG_0:.*]], %[[DEV_ADDR]] ->
%[[ARG_1:.*]] : !fir.llvm_ptr>,
!fir.ref>>) {
!$omp target data map(tofrom: a) use_device_addr(a)
- !CHECK: ^bb0(%[[ARG_0:.*]]: !fir.llvm_ptr>, %[[ARG_1:.*]]:
!fir.ref>>):
!CHECK: %[[VAL_1_DECL:.*]]:2 = hlfir.declare %[[ARG_1]] {fortran_attrs =
#fir.var_attrs, uniq_name = "_QFomp_target_device_addrEa"} :
(!fir.ref>>) -> (!fir.ref>>,
!fir.ref>>)
!CHECK: %[[C10:.*]] = arith.constant 10 : i32
!CHECK: %[[A_BOX:.*]] = fir.load %[[VAL_1_DECL]]#0 :
!fir.ref>>
diff --git a/flang/test/Lower/OpenMP/use-device-ptr-to-use-device-addr.f90
b/flang/test/Lower/OpenMP/use-device-ptr-to-use-device-addr.f90
index 085f5419fa7f88..cb26246a6
[llvm-branch-commits] [libcxx] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
llvmbot wrote: @var-const What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/110677 ___ 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] [MLIR][OpenMP] Document entry block argument-defining clauses (NFC) (PR #109811)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109811
>From 32735e31bba0bc9c062d2039921f9720b8e82f16 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 24 Sep 2024 15:40:17 +0100
Subject: [PATCH] [MLIR][OpenMP] Document entry block argument-defining clauses
(NFC)
This patch adds general information on the proposed approach to unify the
handling and representation of clauses that define entry block arguments
attached to operations that accept them.
---
mlir/docs/Dialects/OpenMPDialect/_index.md | 74 +-
1 file changed, 72 insertions(+), 2 deletions(-)
diff --git a/mlir/docs/Dialects/OpenMPDialect/_index.md
b/mlir/docs/Dialects/OpenMPDialect/_index.md
index 88437b8cf828cc..b4e359284edae6 100644
--- a/mlir/docs/Dialects/OpenMPDialect/_index.md
+++ b/mlir/docs/Dialects/OpenMPDialect/_index.md
@@ -132,7 +132,8 @@ and optional list of `traits`, a list of `clauses` where
all the applicable
would have to be defined in the operation's body are the `summary` and
`description`. For the latter, only the operation itself would have to be
defined, and the description for its clause-inherited arguments is appended
-through the inherited `clausesDescription` property.
+through the inherited `clausesDescription` property. By convention, the list of
+clauses for an operation must be specified in alphabetical order.
If the operation is intended to have a single region, this is better achieved
by
setting the `singleRegion=true` template argument of `OpenMP_Op` rather
manually
@@ -285,7 +286,76 @@ argument's type:
specific `mlir::Attribute` subclass) will be used instead.
- Other attribute types will be represented with their `storageType`.
- It will create `Operands` structure for each operation, which is an
-empty structure subclassing all operand structures defined for the
corresponding `OpenMP_Op`'s clauses.
+empty structure subclassing all operand structures defined for the
corresponding
+`OpenMP_Op`'s clauses.
+
+### Entry Block Argument-Defining Clauses
+
+In their MLIR representation, certain OpenMP clauses introduce a mapping
between
+values defined outside the operation they are applied to and entry block
+arguments for the region of that MLIR operation. This enables, for example, the
+introduction of private copies of the same underlying variable defined outside
+the MLIR operation the clause is attached to. Currently, clauses with this
+property can be classified into three main categories:
+ - Map-like clauses: `map`, `use_device_addr` and `use_device_ptr`.
+ - Reduction-like clauses: `in_reduction`, `reduction` and `task_reduction`.
+ - Privatization clauses: `private`.
+
+All three kinds of entry block argument-defining clauses use a similar custom
+assembly format representation, only differing based on the different pieces of
+information attached to each kind. Below, one example of each is shown:
+
+```mlir
+omp.target map_entries(%x -> %x.m, %y -> %y.m : !llvm.ptr, !llvm.ptr) {
+ // Use %x.m, %y.m in place of %x and %y...
+}
+
+omp.wsloop reduction(@add.i32 %x -> %x.r, byref @add.f32 %y -> %y.r :
!llvm.ptr, !llvm.ptr) {
+ // Use %x.r, %y.r in place of %x and %y...
+}
+
+omp.parallel private(@x.privatizer %x -> %x.p, @y.privatizer %y -> %y.p :
!llvm.ptr, !llvm.ptr) {
+ // Use %x.p, %y.p in place of %x and %y...
+}
+```
+
+As a consequence of parsing and printing the operation's first region entry
+block argument names together with the custom assembly format of these clauses,
+entry block arguments (i.e. the `^bb0(...):` line) must not be explicitly
+defined for these operations. Additionally, it is not possible to implement
this
+feature while allowing each clause to be independently parsed and printed,
+because they need to be printed/parsed together with the corresponding
+operation's first region. They must have a well-defined ordering in which
+multiple of these clauses are specified for a given operation, as well.
+
+The parsing/printing of these clauses together with the region provides the
+ability to define entry block arguments directly after the `->`. Forcing a
+specific ordering between these clauses makes the block argument ordering
+well-defined, which is the property used to easily match each clause with the
+entry block arguments defined by it.
+
+Custom printers and parsers for operation regions based on the entry block
+argument-defining clauses they take are implemented based on the
+`{parse,print}BlockArgRegion` functions, which take care of the sorting and
+formatting of each kind of clause, minimizing code duplication resulting from
+this approach. One example of the custom assembly format of an operation taking
+the `private` and `reduction` clauses is the following:
+
+```tablegen
+let assemblyFormat = clausesAssemblyFormat # [{
+ custom($region, $private_vars, type($private_vars),
+ $private_syms, $reduction_vars, type($reduction_vars), $reduction_byref,
+ $reduction_syms) attr-dict
[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)
https://github.com/vhscampos updated
https://github.com/llvm/llvm-project/pull/110659
>From 1d394d0cbfb4a47d77f466b265671d0c13ebbb3b Mon Sep 17 00:00:00 2001
From: Victor Campos
Date: Thu, 26 Sep 2024 14:44:33 +0100
Subject: [PATCH] [Multilib] Custom flags processing for library selection
Select library variants in the multilib system using the flags passed in
the '-fmultilib-flag=' format.
Multilib flags that were not passed in the command-line have their
default value fed into the library selection mechanism.
A warning is shown if the flag's value is invalid. The closest valid
value is suggested (string edit distance).
Details about this change can be found in this thread:
https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
---
.../clang/Basic/DiagnosticDriverKinds.td | 3 +
clang/include/clang/Driver/Multilib.h | 3 +
clang/lib/Driver/Multilib.cpp | 77 ++-
.../baremetal-multilib-custom-flags.yaml | 57 ++
4 files changed, 139 insertions(+), 1 deletion(-)
create mode 100644 clang/test/Driver/baremetal-multilib-custom-flags.yaml
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 97573fcf20c1fb..2a724e2f483970 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -14,6 +14,9 @@ def err_drv_no_such_file_with_suggestion : Error<
def err_drv_unsupported_opt : Error<"unsupported option '%0'">;
def err_drv_unsupported_opt_with_suggestion : Error<
"unsupported option '%0'; did you mean '%1'?">;
+def warn_drv_unsupported_opt_with_suggestion : Warning<
+ "unsupported option '%0'; did you mean '%1'?">,
+ InGroup;
def err_drv_unsupported_opt_for_target : Error<
"unsupported option '%0' for target '%1'">;
def err_drv_unsupported_opt_for_language_mode : Error<
diff --git a/clang/include/clang/Driver/Multilib.h
b/clang/include/clang/Driver/Multilib.h
index 53ab51a33eea67..88115fa7c31eee 100644
--- a/clang/include/clang/Driver/Multilib.h
+++ b/clang/include/clang/Driver/Multilib.h
@@ -150,6 +150,9 @@ class MultilibSet {
const_iterator begin() const { return Multilibs.begin(); }
const_iterator end() const { return Multilibs.end(); }
+ Multilib::flags_list
+ processCustomFlags(const Driver &D, const Multilib::flags_list &Flags) const;
+
/// Select compatible variants, \returns false if none are compatible
bool select(const Driver &D, const Multilib::flags_list &Flags,
llvm::SmallVectorImpl &) const;
diff --git a/clang/lib/Driver/Multilib.cpp b/clang/lib/Driver/Multilib.cpp
index 4175bc13834ed2..0e3f305848c974 100644
--- a/clang/lib/Driver/Multilib.cpp
+++ b/clang/lib/Driver/Multilib.cpp
@@ -11,6 +11,7 @@
#include "clang/Basic/Version.h"
#include "clang/Driver/Driver.h"
#include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/SmallSet.h"
#include "llvm/ADT/SmallString.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/Compiler.h"
@@ -96,9 +97,83 @@ MultilibSet &MultilibSet::FilterOut(FilterCallback F) {
void MultilibSet::push_back(const Multilib &M) { Multilibs.push_back(M); }
+static void WarnUnclaimedMultilibCustomFlags(
+const Driver &D, const SmallVector &UnclaimedCustomFlagValues,
+const SmallVector &CustomFlagDecls,
+const StringRef MultilibFlagOptionStr) {
+ struct EditDistanceInfo {
+StringRef FlagValue;
+unsigned EditDistance;
+ };
+
+ for (StringRef Unclaimed : UnclaimedCustomFlagValues) {
+std::optional BestCandidate;
+for (const auto &Decl : CustomFlagDecls) {
+ for (StringRef FlagValue : Decl.Values) {
+unsigned EditDistance =
+Unclaimed.edit_distance(FlagValue, /*AllowReplacements=*/false);
+if (!BestCandidate || EditDistance < BestCandidate->EditDistance) {
+ BestCandidate = {std::move(FlagValue), EditDistance};
+}
+ }
+}
+if (!BestCandidate)
+ continue;
+D.Diag(clang::diag::warn_drv_unsupported_opt_with_suggestion)
+<< (MultilibFlagOptionStr + Unclaimed).str()
+<< (MultilibFlagOptionStr + BestCandidate->FlagValue).str();
+ }
+}
+
+Multilib::flags_list
+MultilibSet::processCustomFlags(const Driver &D,
+const Multilib::flags_list &Flags) const {
+ Multilib::flags_list Result;
+ constexpr StringRef MultilibFlagOptionStr = "-fmultilib-flag=";
+ SmallVector CustomFlags;
+
+ for (StringRef Flag : Flags) {
+if (Flag.starts_with(MultilibFlagOptionStr))
+ CustomFlags.push_back(std::move(Flag));
+else
+ Result.push_back(Flag.str());
+ }
+
+ SmallVector UnclaimedCustomFlagValues;
+ llvm::SmallSet TriggeredCustomFlagDecls;
+
+ for (StringRef Flag : llvm::reverse(CustomFlags)) {
+StringRef CustomFlagValue = Flag.drop_front(MultilibFlagOptionStr.size());
+bool Claimed = false;
+for (const CustomFlagDeclaration &Decl : CustomFlagDecls) {
+ if (llvm::i
[llvm-branch-commits] [clang] [Multilib] Add -fmultilib-flag command-line option (PR #110658)
https://github.com/vhscampos updated
https://github.com/llvm/llvm-project/pull/110658
>From 002079817c4d849973941795bb4d19bd822112d5 Mon Sep 17 00:00:00 2001
From: Victor Campos
Date: Thu, 26 Sep 2024 14:44:01 +0100
Subject: [PATCH] [Multilib] Add -fmultilib-flag command-line option
This option is passed through to the multilib system. It is then used in
conjunction with other options to select the proper library variant.
Details about this change can be found in this thread:
https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058
---
clang/include/clang/Driver/Options.td | 2 ++
clang/lib/Driver/ToolChain.cpp | 14 ++
clang/test/Driver/print-multi-selection-flags.c | 7 +++
3 files changed, 23 insertions(+)
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 607ff47a857b8f..30ef1c3bea023e 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5658,6 +5658,8 @@ def print_multi_directory : Flag<["-", "--"],
"print-multi-directory">;
def print_multi_lib : Flag<["-", "--"], "print-multi-lib">;
def print_multi_flags : Flag<["-", "--"], "print-multi-flags-experimental">,
HelpText<"Print the flags used for selecting multilibs (experimental)">;
+def fmultilib_flag : Joined<["-", "--"], "fmultilib-flag=">,
+ Visibility<[ClangOption]>;
def print_multi_os_directory : Flag<["-", "--"], "print-multi-os-directory">,
Flags<[Unsupported]>;
def print_target_triple : Flag<["-", "--"], "print-target-triple">,
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 16f9b629fc538c..70e9d82f596772 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -196,6 +196,16 @@ bool ToolChain::defaultToIEEELongDouble() const {
return PPC_LINUX_DEFAULT_IEEELONGDOUBLE && getTriple().isOSLinux();
}
+static void
+processARMAArch64MultilibCustomFlags(Multilib::flags_list &List,
+ const llvm::opt::ArgList &Args) {
+ for (const Arg *MultilibFlagArg :
+ Args.filtered(options::OPT_fmultilib_flag)) {
+List.push_back(MultilibFlagArg->getAsString(Args));
+MultilibFlagArg->claim();
+ }
+}
+
static void getAArch64MultilibFlags(const Driver &D,
const llvm::Triple &Triple,
const llvm::opt::ArgList &Args,
@@ -227,6 +237,8 @@ static void getAArch64MultilibFlags(const Driver &D,
if (BranchProtectionArg) {
Result.push_back(BranchProtectionArg->getAsString(Args));
}
+
+ processARMAArch64MultilibCustomFlags(Result, Args);
}
static void getARMMultilibFlags(const Driver &D,
@@ -280,6 +292,8 @@ static void getARMMultilibFlags(const Driver &D,
if (BranchProtectionArg) {
Result.push_back(BranchProtectionArg->getAsString(Args));
}
+
+ processARMAArch64MultilibCustomFlags(Result, Args);
}
static void getRISCVMultilibFlags(const Driver &D, const llvm::Triple &Triple,
diff --git a/clang/test/Driver/print-multi-selection-flags.c
b/clang/test/Driver/print-multi-selection-flags.c
index 0116c7f5a03b9a..9502eab9eb7457 100644
--- a/clang/test/Driver/print-multi-selection-flags.c
+++ b/clang/test/Driver/print-multi-selection-flags.c
@@ -77,3 +77,10 @@
// CHECK-RV32E-ORDER: --target=riscv32-unknown-none-elf
// CHECK-RV32E-ORDER: -mabi=ilp32e
// CHECK-RV32E-ORDER:
-march=rv32e{{[0-9]+p[0-9]+}}_c{{[0-9]+p[0-9]+}}_zicsr{{[0-9]+p[0-9]+}}
+
+// RUN: %clang -print-multi-flags-experimental --target=armv8m.main-none-eabi
-fmultilib-flag=foo -fmultilib-flag=bar | FileCheck
--check-prefixes=CHECK-MULTILIB-CUSTOM-FLAG,CHECK-ARM-MULTILIB-CUSTOM-FLAG %s
+// RUN: %clang -print-multi-flags-experimental --target=aarch64-none-eabi
-fmultilib-flag=foo -fmultilib-flag=bar | FileCheck
--check-prefixes=CHECK-MULTILIB-CUSTOM-FLAG,CHECK-AARCH64-MULTILIB-CUSTOM-FLAG
%s
+// CHECK-ARM-MULTILIB-CUSTOM-FLAG: --target=thumbv8m.main-unknown-none-eabi
+// CHECK-AARCH64-MULTILIB-CUSTOM-FLAG: --target=aarch64-unknown-none-eabi
+// CHECK-MULTILIB-CUSTOM-FLAG-DAG: -fmultilib-flag=foo
+// CHECK-MULTILIB-CUSTOM-FLAG-DAG: -fmultilib-flag=bar
___
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/19.x: Fix libFuzzer not building with pthreads on Windows (#109525) (PR #110663)
mstorsjo wrote: > @mstorsjo What do you think about merging this PR to the release branch? LGTM, the commit has been in main for a couple of weeks, and my nightly builds run fine with it. https://github.com/llvm/llvm-project/pull/110663 ___ 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/19.x: workflows/release-documentation: Submit a pull request with changes (#108247) (PR #110665)
llvmbot wrote: @tru What do you think about merging this PR to the release branch? https://github.com/llvm/llvm-project/pull/110665 ___ 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/19.x: workflows/release-documentation: Submit a pull request with changes (#108247) (PR #110665)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/110665 ___ 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/19.x: workflows/release-documentation: Submit a pull request with changes (#108247) (PR #110665)
llvmbot wrote:
@llvm/pr-subscribers-github-workflow
Author: None (llvmbot)
Changes
Backport 9cd289fa4a7355e1bfd3129ba9c755f979fd0a72
Requested by: @tstellar
---
Full diff: https://github.com/llvm/llvm-project/pull/110665.diff
1 Files Affected:
- (modified) .github/workflows/release-documentation.yml (+8-5)
``diff
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
index 70e5f08b6f72e2..922c5093f13579 100644
--- a/.github/workflows/release-documentation.yml
+++ b/.github/workflows/release-documentation.yml
@@ -72,17 +72,20 @@ jobs:
ref: main
fetch-depth: 0
path: www-releases
+ persist-credentials: false
- name: Upload Release Notes
if: env.upload
env:
- WWW_RELEASES_TOKEN: ${{ secrets.WWW_RELEASES_TOKEN }}
+ GH_TOKEN: ${{ secrets.WWW_RELEASES_TOKEN }}
run: |
- mkdir -p ../www-releases/${{ inputs.release-version }}
- mv ./docs-build/html-export/* ../www-releases/${{
inputs.release-version }}
- cd ../www-releases
+ mkdir -p www-releases/${{ inputs.release-version }}
+ mv ./docs-build/html-export/* www-releases/${{
inputs.release-version }}
+ cd www-releases
+ git checkout -b ${{ inputs.release-version }}
git add ${{ inputs.release-version }}
git config user.email "llvm...@llvm.org"
git config user.name "llvmbot"
git commit -a -m "Add ${{ inputs.release-version }} documentation"
- git push "https://$www_releases_to...@github.com/${{
github.repository_owner }}/www-releases" main:main
+ git push --force
"https://$gh_to...@github.com/llvmbot/www-releases.git"; HEAD:refs/heads/${{
inputs.release-version }}
+ gh pr create -f -B main -H ${{ inputs.release-version }} -R
llvmbot/www-releases
``
https://github.com/llvm/llvm-project/pull/110665
___
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/19.x: workflows/release-documentation: Submit a pull request with changes (#108247) (PR #110665)
https://github.com/llvmbot created
https://github.com/llvm/llvm-project/pull/110665
Backport 9cd289fa4a7355e1bfd3129ba9c755f979fd0a72
Requested by: @tstellar
>From abb161a4a11b2d0077e028a7a40cb570fcc9845a Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Tue, 1 Oct 2024 06:12:03 -0700
Subject: [PATCH] workflows/release-documentation: Submit a pull request with
changes (#108247)
This is instead of pushing directly. Creating a pull request is slightly
more work for the release manager, but it is more secure as we no longer
need a secret with write access to the www-releases repo.
(cherry picked from commit 9cd289fa4a7355e1bfd3129ba9c755f979fd0a72)
---
.github/workflows/release-documentation.yml | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
index 70e5f08b6f72e2..922c5093f13579 100644
--- a/.github/workflows/release-documentation.yml
+++ b/.github/workflows/release-documentation.yml
@@ -72,17 +72,20 @@ jobs:
ref: main
fetch-depth: 0
path: www-releases
+ persist-credentials: false
- name: Upload Release Notes
if: env.upload
env:
- WWW_RELEASES_TOKEN: ${{ secrets.WWW_RELEASES_TOKEN }}
+ GH_TOKEN: ${{ secrets.WWW_RELEASES_TOKEN }}
run: |
- mkdir -p ../www-releases/${{ inputs.release-version }}
- mv ./docs-build/html-export/* ../www-releases/${{
inputs.release-version }}
- cd ../www-releases
+ mkdir -p www-releases/${{ inputs.release-version }}
+ mv ./docs-build/html-export/* www-releases/${{
inputs.release-version }}
+ cd www-releases
+ git checkout -b ${{ inputs.release-version }}
git add ${{ inputs.release-version }}
git config user.email "llvm...@llvm.org"
git config user.name "llvmbot"
git commit -a -m "Add ${{ inputs.release-version }} documentation"
- git push "https://$www_releases_to...@github.com/${{
github.repository_owner }}/www-releases" main:main
+ git push --force
"https://$gh_to...@github.com/llvmbot/www-releases.git"; HEAD:refs/heads/${{
inputs.release-version }}
+ gh pr create -f -B main -H ${{ inputs.release-version }} -R
llvmbot/www-releases
___
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/19.x][libc++] Adjust the version of __cpp_lib_ranges in C++20 mode (PR #109324)
https://github.com/ldionne updated https://github.com/llvm/llvm-project/pull/109324 >From 2978a0a4e42368e49163102e5a6eb9a032605a61 Mon Sep 17 00:00:00 2001 From: Louis Dionne Date: Thu, 19 Sep 2024 15:40:47 -0400 Subject: [PATCH] [libc++] Adjust the version of __cpp_lib_ranges in C++20 mode This is a (very partial) cherry-pick of #101715 to fix this oversight in the LLVM 19 release. --- libcxx/docs/FeatureTestMacroTable.rst | 2 +- libcxx/include/version | 4 ++-- .../algorithm.version.compile.pass.cpp | 14 +++--- .../functional.version.compile.pass.cpp| 14 +++--- .../iterator.version.compile.pass.cpp | 14 +++--- .../memory.version.compile.pass.cpp| 14 +++--- .../ranges.version.compile.pass.cpp| 14 +++--- .../version.version.compile.pass.cpp | 14 +++--- .../generate_feature_test_macro_components.py | 2 +- 9 files changed, 46 insertions(+), 46 deletions(-) diff --git a/libcxx/docs/FeatureTestMacroTable.rst b/libcxx/docs/FeatureTestMacroTable.rst index a1506e115fe70f..4d532e2bd7319e 100644 --- a/libcxx/docs/FeatureTestMacroTable.rst +++ b/libcxx/docs/FeatureTestMacroTable.rst @@ -266,7 +266,7 @@ Status -- - ``__cpp_lib_polymorphic_allocator````201902L`` -- - -``__cpp_lib_ranges`` ``202207L`` +``__cpp_lib_ranges`` ``202110L`` -- - ``__cpp_lib_remove_cvref`` ``201711L`` -- - diff --git a/libcxx/include/version b/libcxx/include/version index fe64343eafbc9c..f53557bbe23d8a 100644 --- a/libcxx/include/version +++ b/libcxx/include/version @@ -182,7 +182,7 @@ __cpp_lib_philox_engine 202406L __cpp_lib_polymorphic_allocator 201902L __cpp_lib_print 202207L __cpp_lib_quoted_string_io 201304L -__cpp_lib_ranges202207L +__cpp_lib_ranges202110L __cpp_lib_ranges_as_const 202207L __cpp_lib_ranges_as_rvalue 202207L @@ -428,7 +428,7 @@ __cpp_lib_void_t 201411L # if _LIBCPP_AVAILABILITY_HAS_PMR # define __cpp_lib_polymorphic_allocator 201902L # endif -# define __cpp_lib_ranges 202207L +# define __cpp_lib_ranges 202110L # define __cpp_lib_remove_cvref 201711L # if !defined(_LIBCPP_HAS_NO_THREADS) && _LIBCPP_AVAILABILITY_HAS_SYNC # define __cpp_lib_semaphore 201907L diff --git a/libcxx/test/std/language.support/support.limits/support.limits.general/algorithm.version.compile.pass.cpp b/libcxx/test/std/language.support/support.limits/support.limits.general/algorithm.version.compile.pass.cpp index ded80060632419..932dea1c5cf007 100644 --- a/libcxx/test/std/language.support/support.limits/support.limits.general/algorithm.version.compile.pass.cpp +++ b/libcxx/test/std/language.support/support.limits/support.limits.general/algorithm.version.compile.pass.cpp @@ -21,7 +21,7 @@ __cpp_lib_default_template_type_for_algorithm_values202403L [C++26] __cpp_lib_freestanding_algorithm202311L [C++26] __cpp_lib_parallel_algorithm201603L [C++17] -__cpp_lib_ranges202207L [C++20] +__cpp_lib_ranges202110L [C++20] __cpp_lib_ranges_contains 202207L [C++23] __cpp_lib_ranges_find_last 202207L [C++23] __cpp_lib_ranges_starts_ends_with 202106L [C++23] @@ -244,8 +244,8 @@ # ifndef __cpp_lib_ranges # error "__cpp_lib_ranges should be defined in c++20" # endif -# if __cpp_lib_ranges != 202207L -# error "__cpp_lib_ranges should have the value 202207L in c++20" +# if __cpp_lib_ranges != 202110L +# error "__cpp_lib_ranges should have the value 202110L in c++20" # endif # ifdef __cpp_lib_ranges_contains @@ -321,8 +321,8 @@ # ifndef __cpp_lib_ranges # error "__cpp_lib_ranges should be defined in c++23" # endif -# if __cpp_lib_ranges != 202207L -# error "__cpp_lib_ranges should have the value 202207L in c++23" +# if __cpp_lib_rang
[llvm-branch-commits] [compiler-rt] release/19.x: Fix libFuzzer not building with pthreads on Windows (#109525) (PR #110663)
llvmbot wrote:
@llvm/pr-subscribers-compiler-rt-sanitizer
Author: None (llvmbot)
Changes
Backport b4130bee6bfd34d8045f02fc9f951bcb5db9d85c
Requested by: @mstorsjo
---
Full diff: https://github.com/llvm/llvm-project/pull/110663.diff
1 Files Affected:
- (modified) compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp (+5)
``diff
diff --git a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
index db80eb383885e6..73eea07cf869ff 100644
--- a/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
+++ b/compiler-rt/lib/fuzzer/FuzzerUtilWindows.cpp
@@ -239,6 +239,10 @@ size_t PageSize() {
}
void SetThreadName(std::thread &thread, const std::string &name) {
+#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) ||
\
+defined(_GLIBCXX_GCC_GTHR_POSIX_H)
+ (void)pthread_setname_np(thread.native_handle(), name.c_str());
+#else
typedef HRESULT(WINAPI * proc)(HANDLE, PCWSTR);
HMODULE kbase = GetModuleHandleA("KernelBase.dll");
proc ThreadNameProc =
@@ -253,6 +257,7 @@ void SetThreadName(std::thread &thread, const std::string
&name) {
}
}
}
+#endif
}
} // namespace fuzzer
``
https://github.com/llvm/llvm-project/pull/110663
___
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/19.x][libc++] Follow-up to "Poison Pills are Too Toxic" (PR #109291)
ldionne wrote: I think this is good to go, the CI is as green as it'll get without rebasing onto `release/19.x` again. https://github.com/llvm/llvm-project/pull/109291 ___ 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] [MLIR][OpenMP] Improve omp.section block arguments handling (PR #110266)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110266
>From 4bc376d594a8d2a3050d6980507c131591e0fbf3 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 26 Sep 2024 11:42:03 +0100
Subject: [PATCH] [MLIR][OpenMP] Improve omp.section block arguments handling
The `omp.section` operation is an outlier in that the block arguments it has
are defined by clauses on the required parent `omp.sections` operation.
This patch updates the definition of this operation introducing the
`BlockArgOpenMPOpInterface` to simplify the handling and verification of these
block arguments, implemented based on the parent `omp.sections`.
---
mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td | 12 +++--
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | 12 +
mlir/test/Dialect/OpenMP/invalid.mlir | 25 +++
mlir/test/Dialect/OpenMP/ops.mlir | 6 +
4 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
index d2a2b44c042fb7..66f63fc02fe2f3 100644
--- a/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ b/mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -207,8 +207,9 @@ def TeamsOp : OpenMP_Op<"teams", traits = [
// 2.8.1 Sections Construct
//===--===//
-def SectionOp : OpenMP_Op<"section", [HasParent<"SectionsOp">],
- singleRegion = true> {
+def SectionOp : OpenMP_Op<"section", traits = [
+BlockArgOpenMPOpInterface, HasParent<"SectionsOp">
+ ], singleRegion = true> {
let summary = "section directive";
let description = [{
A section operation encloses a region which represents one section in a
@@ -218,6 +219,13 @@ def SectionOp : OpenMP_Op<"section",
[HasParent<"SectionsOp">],
operation. This is done to reflect situations where these block arguments
represent variables private to each section.
}];
+ let extraClassDeclaration = [{
+// Override BlockArgOpenMPOpInterface methods based on the parent
+// omp.sections operation. Only forward-declare here because SectionsOp is
+// not completely defined at this point.
+unsigned numPrivateBlockArgs();
+unsigned numReductionBlockArgs();
+ }] # clausesExtraClassDeclaration;
let assemblyFormat = "$region attr-dict";
}
diff --git a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
index bb886323238263..d516c8d9e0be6c 100644
--- a/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ b/mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -1844,6 +1844,18 @@ LogicalResult TeamsOp::verify() {
getReductionByref());
}
+//===--===//
+// SectionOp
+//===--===//
+
+unsigned SectionOp::numPrivateBlockArgs() {
+ return getParentOp().numPrivateBlockArgs();
+}
+
+unsigned SectionOp::numReductionBlockArgs() {
+ return getParentOp().numReductionBlockArgs();
+}
+
//===--===//
// SectionsOp
//===--===//
diff --git a/mlir/test/Dialect/OpenMP/invalid.mlir
b/mlir/test/Dialect/OpenMP/invalid.mlir
index 273aeb975c9c3c..a780efe6d22e16 100644
--- a/mlir/test/Dialect/OpenMP/invalid.mlir
+++ b/mlir/test/Dialect/OpenMP/invalid.mlir
@@ -1584,6 +1584,31 @@ func.func @omp_sections() {
// -
+omp.declare_reduction @add_f32 : f32
+init {
+^bb0(%arg: f32):
+ %0 = arith.constant 0.0 : f32
+ omp.yield (%0 : f32)
+}
+combiner {
+^bb1(%arg0: f32, %arg1: f32):
+ %1 = arith.addf %arg0, %arg1 : f32
+ omp.yield (%1 : f32)
+}
+
+func.func @omp_sections(%x : !llvm.ptr) {
+ omp.sections reduction(@add_f32 %x -> %arg0 : !llvm.ptr) {
+// expected-error @below {{op expected at least 1 entry block argument(s)}}
+omp.section {
+ omp.terminator
+}
+omp.terminator
+ }
+ return
+}
+
+// -
+
func.func @omp_single(%data_var : memref) -> () {
// expected-error @below {{expected equal sizes for allocate and allocator
variables}}
"omp.single" (%data_var) ({
diff --git a/mlir/test/Dialect/OpenMP/ops.mlir
b/mlir/test/Dialect/OpenMP/ops.mlir
index ce3351ba1149f3..a4423782a723bf 100644
--- a/mlir/test/Dialect/OpenMP/ops.mlir
+++ b/mlir/test/Dialect/OpenMP/ops.mlir
@@ -1127,11 +1127,13 @@ func.func @sections_reduction() {
omp.sections reduction(@add_f32 %0 -> %arg0 : !llvm.ptr) {
// CHECK: omp.section
omp.section {
+^bb0(%arg1 : !llvm.ptr):
%1 = arith.constant 2.0 : f32
omp.terminator
}
// CHECK: omp.section
omp.section {
+^bb0(%arg1 : !llvm.ptr):
%1 = arith.constant 3.0 : f32
omp.terminator
}
@@ -1148,11 +1150,13 @@ func.func @sections_reduction_byref() {
omp
[llvm-branch-commits] [llvm] [AMDGPU] Adopt new lowering sequence for `fdiv16` (PR #109295)
https://github.com/arsenm approved this pull request. https://github.com/llvm/llvm-project/pull/109295 ___ 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] edd018e - [X86][APX] Fix wrong encoding of promoted KMOV instructions due to missing NoCD8 (#109579)
Author: Phoebe Wang
Date: 2024-10-01T14:08:12+02:00
New Revision: edd018ead705c6012a62a5d83ccc5d3341bcb20a
URL:
https://github.com/llvm/llvm-project/commit/edd018ead705c6012a62a5d83ccc5d3341bcb20a
DIFF:
https://github.com/llvm/llvm-project/commit/edd018ead705c6012a62a5d83ccc5d3341bcb20a.diff
LOG: [X86][APX] Fix wrong encoding of promoted KMOV instructions due to missing
NoCD8 (#109579)
Promoted KMOV* was encoded with CD8 incorrectly, see
https://godbolt.org/z/cax513hG1
(cherry picked from commit 0d334d83a4c7ce16fa1bc0e5e56bbdeaf01c2b2d)
Added:
Modified:
llvm/lib/Target/X86/X86InstrAVX512.td
llvm/test/MC/Disassembler/X86/apx/kmov.txt
llvm/test/MC/X86/apx/kmov-att.s
llvm/test/MC/X86/apx/kmov-intel.s
Removed:
diff --git a/llvm/lib/Target/X86/X86InstrAVX512.td
b/llvm/lib/Target/X86/X86InstrAVX512.td
index da690aea43f5c0..1bf201f2bb87e4 100644
--- a/llvm/lib/Target/X86/X86InstrAVX512.td
+++ b/llvm/lib/Target/X86/X86InstrAVX512.td
@@ -2617,19 +2617,20 @@ defm VFPCLASS : avx512_fp_fpclass_all<"vfpclass", 0x66,
0x67, SchedWriteFCmp>, E
multiclass avx512_mask_mov opc_kk, bits<8> opc_km, bits<8> opc_mk,
string OpcodeStr, RegisterClass KRC, ValueType vvt,
X86MemOperand x86memop, string Suffix = ""> {
- let isMoveReg = 1, hasSideEffects = 0, SchedRW = [WriteMove],
- explicitOpPrefix = !if(!eq(Suffix, ""), NoExplicitOpPrefix,
ExplicitEVEX) in
- def kk#Suffix : I,
- Sched<[WriteMove]>;
- def km#Suffix : I,
- Sched<[WriteLoad]>;
- def mk#Suffix : I,
- Sched<[WriteStore]>;
+ let explicitOpPrefix = !if(!eq(Suffix, ""), NoExplicitOpPrefix,
ExplicitEVEX) in {
+let isMoveReg = 1, hasSideEffects = 0, SchedRW = [WriteMove] in
+def kk#Suffix : I,
+Sched<[WriteMove]>;
+def km#Suffix : I,
+Sched<[WriteLoad]>, NoCD8;
+def mk#Suffix : I,
+Sched<[WriteStore]>, NoCD8;
+ }
}
multiclass avx512_mask_mov_gpr opc_kr, bits<8> opc_rk,
diff --git a/llvm/test/MC/Disassembler/X86/apx/kmov.txt
b/llvm/test/MC/Disassembler/X86/apx/kmov.txt
index 5d947ff39f2314..45fedbd0da587b 100644
--- a/llvm/test/MC/Disassembler/X86/apx/kmov.txt
+++ b/llvm/test/MC/Disassembler/X86/apx/kmov.txt
@@ -17,6 +17,22 @@
# INTEL: {evex} kmovq k2, k1
0x62,0xf1,0xfc,0x08,0x90,0xd1
+# ATT: {evex} kmovb -16(%rax), %k0
+# INTEL: {evex} kmovb k0, byte ptr [rax - 16]
+0x62,0xf1,0x7d,0x08,0x90,0x40,0xf0
+
+# ATT: {evex} kmovw -16(%rax), %k0
+# INTEL: {evex} kmovw k0, word ptr [rax - 16]
+0x62,0xf1,0x7c,0x08,0x90,0x40,0xf0
+
+# ATT: {evex} kmovd -16(%rax), %k0
+# INTEL: {evex} kmovd k0, dword ptr [rax - 16]
+0x62,0xf1,0xfd,0x08,0x90,0x40,0xf0
+
+# ATT: {evex} kmovq -16(%rax), %k0
+# INTEL: {evex} kmovq k0, qword ptr [rax - 16]
+0x62,0xf1,0xfc,0x08,0x90,0x40,0xf0
+
# ATT-NOT: {evex}
# INTEL-NOT: {evex}
diff --git a/llvm/test/MC/X86/apx/kmov-att.s b/llvm/test/MC/X86/apx/kmov-att.s
index 949ef65be98d4c..5f59e0a505b235 100644
--- a/llvm/test/MC/X86/apx/kmov-att.s
+++ b/llvm/test/MC/X86/apx/kmov-att.s
@@ -1,7 +1,7 @@
# RUN: llvm-mc -triple x86_64 -show-encoding %s | FileCheck %s
# RUN: not llvm-mc -triple i386 -show-encoding %s 2>&1 | FileCheck %s
--check-prefix=ERROR
-# ERROR-COUNT-20: error:
+# ERROR-COUNT-24: error:
# ERROR-NOT: error:
# CHECK: {evex}kmovb %k1, %k2
# CHECK: encoding: [0x62,0xf1,0x7d,0x08,0x90,0xd1]
@@ -15,6 +15,18 @@
# CHECK: {evex}kmovq %k1, %k2
# CHECK: encoding: [0x62,0xf1,0xfc,0x08,0x90,0xd1]
{evex}kmovq %k1, %k2
+# CHECK: {evex} kmovb -16(%rax), %k0
+# CHECK: encoding: [0x62,0xf1,0x7d,0x08,0x90,0x40,0xf0]
+ {evex} kmovb -0x10(%rax), %k0
+# CHECK: {evex} kmovw -16(%rax), %k0
+# CHECK: encoding: [0x62,0xf1,0x7c,0x08,0x90,0x40,0xf0]
+ {evex} kmovw -0x10(%rax), %k0
+# CHECK: {evex} kmovd -16(%rax), %k0
+# CHECK: encoding: [0x62,0xf1,0xfd,0x08,0x90,0x40,0xf0]
+ {evex} kmovd -0x10(%rax), %k0
+# CHECK: {evex} kmovq -16(%rax), %k0
+# CHECK: encoding: [0x62,0xf1,0xfc,0x08,0x90,0x40,0xf0]
+ {evex} kmovq -0x10(%rax), %k0
# CHECK-NOT: {evex}
diff --git a/llvm/test/MC/X86/apx/kmov-intel.s
b/llvm/test/MC/X86/apx/kmov-intel.s
index 0cdbd310062eba..51cec67caf9a04 100644
--- a/llvm/test/MC/X86/apx/kmov-intel.s
+++ b/llvm/test/MC/X86/apx/kmov-intel.s
@@ -12,6 +12,18 @@
# CHECK: {evex}kmovq k2, k1
# CHECK: encoding: [0x62,0xf1,0xfc,0x08,0x90,0xd1]
{evex}kmovq k2, k1
+# CHECK: {evex} kmovb k0, byte ptr [rax - 16]
+# CHECK: encoding: [0x62,0xf1,0x7d,0x08,0x90,0x40,0xf0]
+ {evex} kmovb k0, byte ptr [rax - 0x10]
+# CHECK: {evex} kmovw k0, word ptr [rax - 16]
+# CHECK: encoding: [0x62,0xf1,0x7c,0x08,0x90,0x40,0xf0]
+ {evex} kmovw k0, word ptr [rax - 0x10]
+# CHECK: {ev
[llvm-branch-commits] [libcxx] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
https://github.com/llvmbot milestoned https://github.com/llvm/llvm-project/pull/110677 ___ 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] [libcxxabi] release/19.x: [libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054) (PR #110677)
llvmbot wrote:
@llvm/pr-subscribers-libcxx
Author: None (llvmbot)
Changes
Backport 677e8cd6ff51e178bcb4669104763f71a2de106c
Requested by: @ldionne
---
Full diff: https://github.com/llvm/llvm-project/pull/110677.diff
7 Files Affected:
- (modified) libcxx/lib/abi/CHANGELOG.TXT (+30)
- (modified)
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
(-7)
- (modified)
libcxx/lib/abi/x86_64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
(-7)
- (modified) libcxxabi/lib/cxxabiv1.exp (-3)
- (modified) libcxxabi/lib/itanium-base.exp (-1)
- (added) libcxxabi/lib/symbols-not-reexported.exp (+13)
- (modified) libcxxabi/src/CMakeLists.txt (+9-1)
``diff
diff --git a/libcxx/lib/abi/CHANGELOG.TXT b/libcxx/lib/abi/CHANGELOG.TXT
index 32526f1786c6d9..68c9d980a016ea 100644
--- a/libcxx/lib/abi/CHANGELOG.TXT
+++ b/libcxx/lib/abi/CHANGELOG.TXT
@@ -16,6 +16,36 @@ New entries should be added directly below the "Version"
header.
Version 19.0
+* [libc++] Avoid re-exporting a few specific symbols from libc++abi
+
+ In 6a884a9aef39, I synchronized the export list of libc++abi to the
+ export list of libc++. From the linker's perspective, this caused
+ these symbols to be taken from libc++.dylib instead of libc++abi.dylib.
+
+ However, that can be problematic when back-deploying. Indeed, this means
+ that the linker will encode an undefined reference to be fullfilled by
+ libc++.dylib, but when backdeploying against an older system, that symbol
+ might only be available in libc++abi.dylib.
+
+ Most of the symbols that started being re-exported after 6a884a9aef39
+ turn out to be implementation details of libc++abi, so nobody really
+ depends on them and this back-deployment issue is inconsequential.
+
+ However, we ran into issues with a few of these symbols while testing
+ LLVM 19, which led to this patch.
+
+ In the future, a follow-up cleanup would be to stop exporting most of
+ the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
+ since they are implementation details that nobody should be relying
+ on.
+
+ -apple-darwin
+ ---
+ Symbol not reexported anymore: ___cxa_rethrow_primary_exception
+ Symbol not reexported anymore: __ZTIN10__cxxabiv117__class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv120__si_class_type_infoE
+ Symbol not reexported anymore: __ZTIN10__cxxabiv121__vmi_class_type_infoE
+
* [libc++] Always keep libc++abi re-exports up-to-date
This patch makes sure that the set of libc++abi symbols re-exported from
libc++
diff --git
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
index 917388f86811fe..32acae46e292d7 100644
---
a/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
+++
b/libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist
@@ -78,12 +78,9 @@
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__enum_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv116__shim_type_infoE', 'type':
'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__array_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__class_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv117__pbase_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv119__pointer_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv120__function_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv120__si_class_type_infoE',
'type': 'U'}
-{'is_defined': False, 'name': '__ZTIN10__cxxabiv121__vmi_class_type_infoE',
'type': 'U'}
{'is_defined': False, 'name': '__ZTIN10__cxxabiv123__fundamental_type_infoE',
'type': 'U'}
{'is_defined': False, 'name':
'__ZTIN10__cxxabiv129__pointer_to_member_type_infoE', 'type': 'U'}
{'is_defined': False, 'name': '__ZTIPDh', 'type': 'U'}
@@ -2002,12 +1999,9 @@
{'is_defined': True, 'name': '__ZTIN10__cxxabiv116__enum_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv116__shim_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__array_type_infoE', 'type':
'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__class_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv117__pbase_type_infoE', 'type':
'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv119__pointer_type_infoE',
'type': 'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv120__function_type_infoE',
'type': 'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv120__si_class_type_infoE',
'type': 'I'}
-{'is_defined': True, 'name': '__ZTIN10__cxxabiv121__vmi_class_type_infoE',
'type': 'I'}
{'is_defined': True, 'name': '__ZTIN10__cxxabiv123__fundamental_type_infoE',
'type': 'I'}
{'is_defined': True, 'name':
'_
[llvm-branch-commits] [llvm] AMDGPU: Handle folding frame indexes into add with immediate (PR #110738)
https://github.com/arsenm created
https://github.com/llvm/llvm-project/pull/110738
Frame index materialization can fold the constant offset into
adds with immediates. The mubuf expansion is more complicated because
we have to also insert the shift, so restrict this to one use for now.
This is preparation to avoid regressions in a future patch.
This also misses some cases due to visitation order. It depends on
the immediate already folding into the instruction.
>From fccd15f8530a1d685046e2f7ee248677380f0749 Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Tue, 1 Oct 2024 23:53:51 +0400
Subject: [PATCH] AMDGPU: Handle folding frame indexes into add with immediate
Frame index materialization can fold the constant offset into
adds with immediates. The mubuf expansion is more complicated because
we have to also insert the shift, so restrict this to one use for now.
This is preparation to avoid regressions in a future patch.
This also misses some cases due to visitation order. It depends on
the immediate already folding into the instruction.
---
llvm/lib/Target/AMDGPU/SIFoldOperands.cpp | 14 ++
llvm/test/CodeGen/AMDGPU/flat-scratch.ll | 6 ++
.../AMDGPU/fold-operands-frame-index.gfx10.mir | 3 +--
.../AMDGPU/fold-operands-frame-index.mir | 18 ++
.../materialize-frame-index-sgpr.gfx10.ll | 6 +++---
.../AMDGPU/materialize-frame-index-sgpr.ll | 12 ++--
6 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
index 1e2c77b08b9a63..fea84247f5ad88 100644
--- a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
+++ b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
@@ -194,6 +194,20 @@ bool SIFoldOperandsImpl::frameIndexMayFold(
return false;
const unsigned Opc = UseMI.getOpcode();
+ switch (Opc) {
+ case AMDGPU::S_ADD_I32:
+ case AMDGPU::V_ADD_U32_e32:
+ case AMDGPU::V_ADD_CO_U32_e32:
+// TODO: Handle e64 variants
+// TODO: Possibly relax hasOneUse. It matters more for mubuf, since we have
+// to insert the wave size shift at every point we use the index.
+// TODO: Fix depending on visit order to fold immediates into the operand
+return UseMI.getOperand(OpNo == 1 ? 2 : 1).isImm() &&
+ MRI->hasOneNonDBGUse(UseMI.getOperand(OpNo).getReg());
+ default:
+break;
+ }
+
if (TII->isMUBUF(UseMI))
return OpNo == AMDGPU::getNamedOperandIdx(Opc, AMDGPU::OpName::vaddr);
if (!TII->isFLATScratch(UseMI))
diff --git a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
index ef9590b3fd33fa..af0b6360527016 100644
--- a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
+++ b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
@@ -4705,8 +4705,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s0
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s1
; GFX10-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-NEXT:s_movk_i32 s0, 0x810
-; GFX10-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-NEXT:v_mov_b32_e32 v1, v0
; GFX10-NEXT:v_mov_b32_e32 v2, v0
; GFX10-NEXT:v_mov_b32_e32 v3, v0
@@ -4823,8 +4822,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s2
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s3
; GFX10-PAL-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-PAL-NEXT:s_movk_i32 s0, 0x810
-; GFX10-PAL-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-PAL-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-PAL-NEXT:v_mov_b32_e32 v1, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v2, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v3, v0
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
index 76183ece264ffc..d26d7dd4a98d9e 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
@@ -13,8 +13,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__v_add_u32_e32__const_v_fi
-; CHECK: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 %stack.0,
implicit $exec
-; CHECK-NEXT: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128,
[[V_MOV_B32_e32_]], implicit $exec
+; CHECK: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128, %stack.0,
implicit $exec
; CHECK-NEXT: $vgpr0 = COPY [[V_ADD_U32_e32_]]
; CHECK-NEXT: SI_RETURN implicit $vgpr0
%0:vgpr_32 = V_MOV_B32_e32 %stack.0, implicit $exec
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
index da094745ec3d47..3169d31548b206 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
@@ -14,8 +14,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_f
[llvm-branch-commits] [llvm] AMDGPU: Handle folding frame indexes into add with immediate (PR #110738)
arsenm wrote: > [!WARNING] > This pull request is not mergeable via GitHub because a downstack PR is > open. Once all requirements are satisfied, merge this PR as a stack href="https://app.graphite.dev/github/pr/llvm/llvm-project/110738?utm_source=stack-comment-downstack-mergeability-warning"; > >on Graphite. > https://graphite.dev/docs/merge-pull-requests";>Learn more * **#110738** https://app.graphite.dev/github/pr/llvm/llvm-project/110738?utm_source=stack-comment-icon"; target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="10px" height="10px"/> 👈 * **#110737** https://app.graphite.dev/github/pr/llvm/llvm-project/110737?utm_source=stack-comment-icon"; target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="10px" height="10px"/> * `main` This stack of pull requests is managed by Graphite. https://stacking.dev/?utm_source=stack-comment";>Learn more about stacking. Join @arsenm and the rest of your teammates on https://graphite.dev?utm-source=stack-comment";>https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" width="11px" height="11px"/> Graphite https://github.com/llvm/llvm-project/pull/110738 ___ 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] AMDGPU: Handle folding frame indexes into add with immediate (PR #110738)
llvmbot wrote:
@llvm/pr-subscribers-backend-amdgpu
Author: Matt Arsenault (arsenm)
Changes
Frame index materialization can fold the constant offset into
adds with immediates. The mubuf expansion is more complicated because
we have to also insert the shift, so restrict this to one use for now.
This is preparation to avoid regressions in a future patch.
This also misses some cases due to visitation order. It depends on
the immediate already folding into the instruction.
---
Full diff: https://github.com/llvm/llvm-project/pull/110738.diff
6 Files Affected:
- (modified) llvm/lib/Target/AMDGPU/SIFoldOperands.cpp (+14)
- (modified) llvm/test/CodeGen/AMDGPU/flat-scratch.ll (+2-4)
- (modified) llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
(+1-2)
- (modified) llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir (+6-12)
- (modified) llvm/test/CodeGen/AMDGPU/materialize-frame-index-sgpr.gfx10.ll
(+3-3)
- (modified) llvm/test/CodeGen/AMDGPU/materialize-frame-index-sgpr.ll (+6-6)
``diff
diff --git a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
index 1e2c77b08b9a63..fea84247f5ad88 100644
--- a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
+++ b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
@@ -194,6 +194,20 @@ bool SIFoldOperandsImpl::frameIndexMayFold(
return false;
const unsigned Opc = UseMI.getOpcode();
+ switch (Opc) {
+ case AMDGPU::S_ADD_I32:
+ case AMDGPU::V_ADD_U32_e32:
+ case AMDGPU::V_ADD_CO_U32_e32:
+// TODO: Handle e64 variants
+// TODO: Possibly relax hasOneUse. It matters more for mubuf, since we have
+// to insert the wave size shift at every point we use the index.
+// TODO: Fix depending on visit order to fold immediates into the operand
+return UseMI.getOperand(OpNo == 1 ? 2 : 1).isImm() &&
+ MRI->hasOneNonDBGUse(UseMI.getOperand(OpNo).getReg());
+ default:
+break;
+ }
+
if (TII->isMUBUF(UseMI))
return OpNo == AMDGPU::getNamedOperandIdx(Opc, AMDGPU::OpName::vaddr);
if (!TII->isFLATScratch(UseMI))
diff --git a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
index ef9590b3fd33fa..af0b6360527016 100644
--- a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
+++ b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
@@ -4705,8 +4705,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s0
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s1
; GFX10-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-NEXT:s_movk_i32 s0, 0x810
-; GFX10-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-NEXT:v_mov_b32_e32 v1, v0
; GFX10-NEXT:v_mov_b32_e32 v2, v0
; GFX10-NEXT:v_mov_b32_e32 v3, v0
@@ -4823,8 +4822,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s2
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s3
; GFX10-PAL-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-PAL-NEXT:s_movk_i32 s0, 0x810
-; GFX10-PAL-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-PAL-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-PAL-NEXT:v_mov_b32_e32 v1, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v2, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v3, v0
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
index 76183ece264ffc..d26d7dd4a98d9e 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
@@ -13,8 +13,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__v_add_u32_e32__const_v_fi
-; CHECK: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 %stack.0,
implicit $exec
-; CHECK-NEXT: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128,
[[V_MOV_B32_e32_]], implicit $exec
+; CHECK: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128, %stack.0,
implicit $exec
; CHECK-NEXT: $vgpr0 = COPY [[V_ADD_U32_e32_]]
; CHECK-NEXT: SI_RETURN implicit $vgpr0
%0:vgpr_32 = V_MOV_B32_e32 %stack.0, implicit $exec
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
index da094745ec3d47..3169d31548b206 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
@@ -14,8 +14,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__s_add_i32__fi_const
-; CHECK: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 %stack.0
-; CHECK-NEXT: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 [[S_MOV_B32_]],
128, implicit-def $scc
+; CHECK: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 %stack.0, 128,
implicit-def $scc
; CHECK-NEXT: $sgpr4 = COPY [[S_ADD_I32_]]
; CHECK-NEXT: SI_RETURN implicit $sgpr4
%0:sreg_32 = S_MOV_B32 %stack.0
@@ -35,8 +34,7 @@ stack:
body:
[llvm-branch-commits] [llvm] AMDGPU: Handle folding frame indexes into add with immediate (PR #110738)
https://github.com/arsenm updated
https://github.com/llvm/llvm-project/pull/110738
>From 295561a4936e932aa41fe7d80ec2aafb94f49a8e Mon Sep 17 00:00:00 2001
From: Matt Arsenault
Date: Tue, 1 Oct 2024 23:53:51 +0400
Subject: [PATCH 1/2] AMDGPU: Handle folding frame indexes into add with
immediate
Frame index materialization can fold the constant offset into
adds with immediates. The mubuf expansion is more complicated because
we have to also insert the shift, so restrict this to one use for now.
This is preparation to avoid regressions in a future patch.
This also misses some cases due to visitation order. It depends on
the immediate already folding into the instruction.
---
llvm/lib/Target/AMDGPU/SIFoldOperands.cpp | 14 ++
llvm/test/CodeGen/AMDGPU/flat-scratch.ll | 6 ++
.../AMDGPU/fold-operands-frame-index.gfx10.mir | 3 +--
.../AMDGPU/fold-operands-frame-index.mir | 18 ++
.../materialize-frame-index-sgpr.gfx10.ll | 6 +++---
.../AMDGPU/materialize-frame-index-sgpr.ll | 12 ++--
6 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
index 1e2c77b08b9a63..fea84247f5ad88 100644
--- a/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
+++ b/llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
@@ -194,6 +194,20 @@ bool SIFoldOperandsImpl::frameIndexMayFold(
return false;
const unsigned Opc = UseMI.getOpcode();
+ switch (Opc) {
+ case AMDGPU::S_ADD_I32:
+ case AMDGPU::V_ADD_U32_e32:
+ case AMDGPU::V_ADD_CO_U32_e32:
+// TODO: Handle e64 variants
+// TODO: Possibly relax hasOneUse. It matters more for mubuf, since we have
+// to insert the wave size shift at every point we use the index.
+// TODO: Fix depending on visit order to fold immediates into the operand
+return UseMI.getOperand(OpNo == 1 ? 2 : 1).isImm() &&
+ MRI->hasOneNonDBGUse(UseMI.getOperand(OpNo).getReg());
+ default:
+break;
+ }
+
if (TII->isMUBUF(UseMI))
return OpNo == AMDGPU::getNamedOperandIdx(Opc, AMDGPU::OpName::vaddr);
if (!TII->isFLATScratch(UseMI))
diff --git a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
index ef9590b3fd33fa..af0b6360527016 100644
--- a/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
+++ b/llvm/test/CodeGen/AMDGPU/flat-scratch.ll
@@ -4705,8 +4705,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s0
; GFX10-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s1
; GFX10-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-NEXT:s_movk_i32 s0, 0x810
-; GFX10-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-NEXT:v_mov_b32_e32 v1, v0
; GFX10-NEXT:v_mov_b32_e32 v2, v0
; GFX10-NEXT:v_mov_b32_e32 v3, v0
@@ -4823,8 +4822,7 @@ define amdgpu_ps void @large_offset() {
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_LO), s2
; GFX10-PAL-NEXT:s_setreg_b32 hwreg(HW_REG_FLAT_SCR_HI), s3
; GFX10-PAL-NEXT:v_mov_b32_e32 v0, 0
-; GFX10-PAL-NEXT:s_movk_i32 s0, 0x810
-; GFX10-PAL-NEXT:s_addk_i32 s0, 0x3c0
+; GFX10-PAL-NEXT:s_movk_i32 s0, 0xbd0
; GFX10-PAL-NEXT:v_mov_b32_e32 v1, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v2, v0
; GFX10-PAL-NEXT:v_mov_b32_e32 v3, v0
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
index 0d6511cbfceb21..b46c672ea8edd2 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.gfx10.mir
@@ -13,8 +13,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__v_add_u32_e32__const_v_fi
-; CHECK: [[V_MOV_B32_e32_:%[0-9]+]]:vgpr_32 = V_MOV_B32_e32 %stack.0,
implicit $exec
-; CHECK-NEXT: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128,
[[V_MOV_B32_e32_]], implicit $exec
+; CHECK: [[V_ADD_U32_e32_:%[0-9]+]]:vgpr_32 = V_ADD_U32_e32 128, %stack.0,
implicit $exec
; CHECK-NEXT: $vgpr0 = COPY [[V_ADD_U32_e32_]]
; CHECK-NEXT: SI_RETURN implicit $vgpr0
%0:vgpr_32 = V_MOV_B32_e32 %stack.0, implicit $exec
diff --git a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
index aa91a4f9f988fc..97ba179afbbe03 100644
--- a/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
+++ b/llvm/test/CodeGen/AMDGPU/fold-operands-frame-index.mir
@@ -14,8 +14,7 @@ stack:
body: |
bb.0:
; CHECK-LABEL: name: fold_frame_index__s_add_i32__fi_const
-; CHECK: [[S_MOV_B32_:%[0-9]+]]:sreg_32 = S_MOV_B32 %stack.0
-; CHECK-NEXT: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 [[S_MOV_B32_]],
128, implicit-def $scc
+; CHECK: [[S_ADD_I32_:%[0-9]+]]:sreg_32 = S_ADD_I32 %stack.0, 128,
implicit-def $scc
; CHECK-NEXT: $sgpr4 = COPY [[S_ADD_I32_]]
; CHECK-NEXT: SI_RETURN implicit $s
[llvm-branch-commits] [libcxx] [llvm] [libc++][C++03] Use `__cxx03/` headers in C++03 mode (PR #109002)
Zingam wrote: @philnik777 These changes seem significant enough to affect already opened PRs and to confuse the authors who are unaware of the changes. So basically you are surrounding all C++11 mode headers with: ```C++ #include <__configuration/cxx03.h> #if defined(_LIBCPP_CXX03_LANG) && !defined(_LIBCPP_CXX03_USE_MAIN_HEADERS) # include <__cxx03/any> #else ... #endif // _LIBCPP_CXX03_LANG ``` And these should be added even to headers not available in C++03 mode, right? Is there anything else that needs to be observed/implemented in PRs? An headers? https://github.com/llvm/llvm-project/pull/109002 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
