date:20250319

[llvm-branch-commits] [clang] [clang-tools-extra] [clang] improve class type sugar preservation in pointers to members (PR #130537)

2025-03-19 Thread Erich Keane via llvm-branch-commits


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

just want for 1 FIXME comment, else I've reviewed as well as I can and found 
nothing concerning.

https://github.com/llvm/llvm-project/pull/130537
___
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] [clang-tools-extra] [clang] improve class type sugar preservation in pointers to members (PR #130537)

2025-03-19 Thread Erich Keane via llvm-branch-commits


https://github.com/erichkeane edited 
https://github.com/llvm/llvm-project/pull/130537
___
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] [clang-tools-extra] [clang] improve class type sugar preservation in pointers to members (PR #130537)

2025-03-19 Thread Erich Keane via llvm-branch-commits



@@ -1355,7 +1355,7 @@ class BlockPointerTypeLoc : public 
PointerLikeTypeLochttps://github.com/llvm/llvm-project/pull/130537
___
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/20.x: [llvm] Fix crash when complex deinterleaving operates on an unrolled loop (#129735) (PR #132031)

2025-03-19 Thread via llvm-branch-commits


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

Backport 3f4b2f12a1e3e87e4bfb86937cc1ccdd4d38dcf5

Requested by: @NickGuy-Arm

>From 27efd9836497ecd26d2a525b5b3d9fa2bd95b9c1 Mon Sep 17 00:00:00 2001
From: Nicholas Guy 
Date: Wed, 19 Mar 2025 13:44:02 +
Subject: [PATCH] [llvm] Fix crash when complex deinterleaving operates on an
 unrolled loop (#129735)

When attempting to perform complex deinterleaving on an unrolled loop
containing a reduction, the complex deinterleaving pass would fail to
accommodate the wider types when accumulating the unrolled paths.
Instead of trying to alter the incoming IR to fit expectations, the pass
should instead decide against processing any reduction that results in a
non-complex or non-vector value.

(cherry picked from commit 3f4b2f12a1e3e87e4bfb86937cc1ccdd4d38dcf5)
---
 .../lib/CodeGen/ComplexDeinterleavingPass.cpp |  11 +
 .../complex-deinterleaving-unrolled-cdot.ll   | 191 ++
 2 files changed, 202 insertions(+)
 create mode 100644 
llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll

diff --git a/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp 
b/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
index 92053ed561901..4cd378f9aa595 100644
--- a/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
+++ b/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
@@ -1741,6 +1741,17 @@ void 
ComplexDeinterleavingGraph::identifyReductionNodes() {
   LLVM_DEBUG(
   dbgs() << "Identified single reduction starting from instruction: "
  << *Real << "/" << *ReductionInfo[Real].second << "\n");
+
+  // Reducing to a single vector is not supported, only permit reducing 
down
+  // to scalar values.
+  // Doing this here will leave the prior node in the graph,
+  // however with no uses the node will be unreachable by the replacement
+  // process. That along with the usage outside the graph should prevent 
the
+  // replacement process from kicking off at all for this graph.
+  // TODO Add support for reducing to a single vector value
+  if (ReductionInfo[Real].second->getType()->isVectorTy())
+continue;
+
   Processed[i] = true;
   auto RootNode = prepareCompositeNode(
   ComplexDeinterleavingOperation::ReductionSingle, Real, nullptr);
diff --git a/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll 
b/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll
new file mode 100644
index 0..faefaf9bad7b1
--- /dev/null
+++ b/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll
@@ -0,0 +1,191 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 5
+; RUN: opt -S --passes=complex-deinterleaving %s --mattr=+sve2 -o - | 
FileCheck %s --check-prefix=CHECK-SVE2
+; RUN: opt -S --passes=complex-deinterleaving %s --mattr=+sve -o - | FileCheck 
%s --check-prefix=CHECK-SVE
+; RUN: opt -S --passes=complex-deinterleaving %s -o - | FileCheck %s 
--check-prefix=CHECK-NOSVE
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-none-unknown-elf"
+
+define i32 @cdotp_i8_rot0( %a0,  %b0, 
 %a1,  %b1) {
+; CHECK-SVE2-LABEL: define i32 @cdotp_i8_rot0(
+; CHECK-SVE2-SAME:  [[A0:%.*]],  
[[B0:%.*]],  [[A1:%.*]],  [[B1:%.*]]) 
#[[ATTR0:[0-9]+]] {
+; CHECK-SVE2-NEXT:  [[ENTRY:.*]]:
+; CHECK-SVE2-NEXT:br label %[[VECTOR_BODY:.*]]
+; CHECK-SVE2:   [[VECTOR_BODY]]:
+; CHECK-SVE2-NEXT:[[VEC_PHI:%.*]] = phi  [ 
zeroinitializer, %[[ENTRY]] ], [ [[PARTIAL_REDUCE33:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-SVE2-NEXT:[[VEC_PHI25:%.*]] = phi  [ 
zeroinitializer, %[[ENTRY]] ], [ [[PARTIAL_REDUCE34:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-SVE2-NEXT:[[A0_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[A0]])
+; CHECK-SVE2-NEXT:[[A0_REAL:%.*]] = extractvalue { , 
 } [[A0_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[A0_IMAG:%.*]] = extractvalue { , 
 } [[A0_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[A1_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[A1]])
+; CHECK-SVE2-NEXT:[[A1_REAL:%.*]] = extractvalue { , 
 } [[A1_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[A1_IMAG:%.*]] = extractvalue { , 
 } [[A1_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[A0_REAL_EXT:%.*]] = sext  
[[A0_REAL]] to 
+; CHECK-SVE2-NEXT:[[A1_REAL_EXT:%.*]] = sext  
[[A1_REAL]] to 
+; CHECK-SVE2-NEXT:[[B0_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[B0]])
+; CHECK-SVE2-NEXT:[[B0_REAL:%.*]] = extractvalue { , 
 } [[B0_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[B0_IMAG:%.*]] = extractvalue { , 
 } [[B0_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[B1_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[B1]])
+; CHECK-SVE2-NEXT:[[B1_REAL:%.*]] = extractvalue { , 
 } [[B1_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[B1_IMAG:%.*]] = extractvalue {

[llvm-branch-commits] [llvm] release/20.x: [llvm] Fix crash when complex deinterleaving operates on an unrolled loop (#129735) (PR #132031)

2025-03-19 Thread via llvm-branch-commits


https://github.com/llvmbot milestoned 
https://github.com/llvm/llvm-project/pull/132031
___
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/20.x: [llvm] Fix crash when complex deinterleaving operates on an unrolled loop (#129735) (PR #132031)

2025-03-19 Thread via llvm-branch-commits


llvmbot wrote:




@llvm/pr-subscribers-backend-aarch64

Author: None (llvmbot)


Changes

Backport 3f4b2f12a1e3e87e4bfb86937cc1ccdd4d38dcf5

Requested by: @NickGuy-Arm

---

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


2 Files Affected:

- (modified) llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp (+11) 
- (added) llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll 
(+191) 


``diff
diff --git a/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp 
b/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
index 92053ed561901..4cd378f9aa595 100644
--- a/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
+++ b/llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp
@@ -1741,6 +1741,17 @@ void 
ComplexDeinterleavingGraph::identifyReductionNodes() {
   LLVM_DEBUG(
   dbgs() << "Identified single reduction starting from instruction: "
  << *Real << "/" << *ReductionInfo[Real].second << "\n");
+
+  // Reducing to a single vector is not supported, only permit reducing 
down
+  // to scalar values.
+  // Doing this here will leave the prior node in the graph,
+  // however with no uses the node will be unreachable by the replacement
+  // process. That along with the usage outside the graph should prevent 
the
+  // replacement process from kicking off at all for this graph.
+  // TODO Add support for reducing to a single vector value
+  if (ReductionInfo[Real].second->getType()->isVectorTy())
+continue;
+
   Processed[i] = true;
   auto RootNode = prepareCompositeNode(
   ComplexDeinterleavingOperation::ReductionSingle, Real, nullptr);
diff --git a/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll 
b/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll
new file mode 100644
index 0..faefaf9bad7b1
--- /dev/null
+++ b/llvm/test/CodeGen/AArch64/complex-deinterleaving-unrolled-cdot.ll
@@ -0,0 +1,191 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py 
UTC_ARGS: --version 5
+; RUN: opt -S --passes=complex-deinterleaving %s --mattr=+sve2 -o - | 
FileCheck %s --check-prefix=CHECK-SVE2
+; RUN: opt -S --passes=complex-deinterleaving %s --mattr=+sve -o - | FileCheck 
%s --check-prefix=CHECK-SVE
+; RUN: opt -S --passes=complex-deinterleaving %s -o - | FileCheck %s 
--check-prefix=CHECK-NOSVE
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-none-unknown-elf"
+
+define i32 @cdotp_i8_rot0( %a0,  %b0, 
 %a1,  %b1) {
+; CHECK-SVE2-LABEL: define i32 @cdotp_i8_rot0(
+; CHECK-SVE2-SAME:  [[A0:%.*]],  
[[B0:%.*]],  [[A1:%.*]],  [[B1:%.*]]) 
#[[ATTR0:[0-9]+]] {
+; CHECK-SVE2-NEXT:  [[ENTRY:.*]]:
+; CHECK-SVE2-NEXT:br label %[[VECTOR_BODY:.*]]
+; CHECK-SVE2:   [[VECTOR_BODY]]:
+; CHECK-SVE2-NEXT:[[VEC_PHI:%.*]] = phi  [ 
zeroinitializer, %[[ENTRY]] ], [ [[PARTIAL_REDUCE33:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-SVE2-NEXT:[[VEC_PHI25:%.*]] = phi  [ 
zeroinitializer, %[[ENTRY]] ], [ [[PARTIAL_REDUCE34:%.*]], %[[VECTOR_BODY]] ]
+; CHECK-SVE2-NEXT:[[A0_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[A0]])
+; CHECK-SVE2-NEXT:[[A0_REAL:%.*]] = extractvalue { , 
 } [[A0_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[A0_IMAG:%.*]] = extractvalue { , 
 } [[A0_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[A1_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[A1]])
+; CHECK-SVE2-NEXT:[[A1_REAL:%.*]] = extractvalue { , 
 } [[A1_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[A1_IMAG:%.*]] = extractvalue { , 
 } [[A1_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[A0_REAL_EXT:%.*]] = sext  
[[A0_REAL]] to 
+; CHECK-SVE2-NEXT:[[A1_REAL_EXT:%.*]] = sext  
[[A1_REAL]] to 
+; CHECK-SVE2-NEXT:[[B0_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[B0]])
+; CHECK-SVE2-NEXT:[[B0_REAL:%.*]] = extractvalue { , 
 } [[B0_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[B0_IMAG:%.*]] = extractvalue { , 
 } [[B0_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[B1_DEINTERLEAVED:%.*]] = tail call { ,  } @llvm.vector.deinterleave2.nxv32i8( 
[[B1]])
+; CHECK-SVE2-NEXT:[[B1_REAL:%.*]] = extractvalue { , 
 } [[B1_DEINTERLEAVED]], 0
+; CHECK-SVE2-NEXT:[[B1_IMAG:%.*]] = extractvalue { , 
 } [[B1_DEINTERLEAVED]], 1
+; CHECK-SVE2-NEXT:[[B0_REAL_EXT:%.*]] = sext  
[[B0_REAL]] to 
+; CHECK-SVE2-NEXT:[[B1_REAL_EXT:%.*]] = sext  
[[B1_REAL]] to 
+; CHECK-SVE2-NEXT:[[TMP0:%.*]] = mul nsw  
[[B0_REAL_EXT]], [[A0_REAL_EXT]]
+; CHECK-SVE2-NEXT:[[TMP1:%.*]] = mul nsw  
[[B1_REAL_EXT]], [[A1_REAL_EXT]]
+; CHECK-SVE2-NEXT:[[A0_IMAG_EXT:%.*]] = sext  
[[A0_IMAG]] to 
+; CHECK-SVE2-NEXT:[[A1_IMAG_EXT:%.*]] = sext  
[[A1_IMAG]] to 
+; CHECK-SVE2-NEXT:[[B0_IMAG_EXT:%.*]] = sext  
[[B0_IMAG]] to 
+; CHECK-SVE2-NEXT:[[B1_IMAG_EXT:%.*]] = sext  
[[B1_IMAG]] to 
+; CHECK-SVE2-NEXT:

[llvm-branch-commits] [llvm] release/20.x: [llvm] Fix crash when complex deinterleaving operates on an unrolled loop (#129735) (PR #132031)

2025-03-19 Thread via llvm-branch-commits


llvmbot wrote:

@igogo-x86 What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/132031
___
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][NFC] Mark GEPs in flat offset folding tests as inbounds (PR #131994)

2025-03-19 Thread Fabian Ritter via llvm-branch-commits


ritter-x2a 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/131994?utm_source=stack-comment-downstack-mergeability-warning";
>  >on Graphite.
> https://graphite.dev/docs/merge-pull-requests";>Learn more

* **#131994** https://app.graphite.dev/github/pr/llvm/llvm-project/131994?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/131994?utm_source=stack-comment-view-in-graphite";
 target="_blank">(View in Graphite)
* **#131862** https://app.graphite.dev/github/pr/llvm/llvm-project/131862?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>: 1 other dependent PR 
([#131863](https://github.com/llvm/llvm-project/pull/131863) https://app.graphite.dev/github/pr/llvm/llvm-project/131863?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>)
* **#130617** https://app.graphite.dev/github/pr/llvm/llvm-project/130617?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>
* **#130616** https://app.graphite.dev/github/pr/llvm/llvm-project/130616?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 https://graphite.dev?utm-source=stack-comment";>Graphite. Learn 
more about https://stacking.dev/?utm_source=stack-comment";>stacking.


https://github.com/llvm/llvm-project/pull/131994
___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


ilovepi 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/132103?utm_source=stack-comment-downstack-mergeability-warning";
>  >on Graphite.
> https://graphite.dev/docs/merge-pull-requests";>Learn more

* **#132103** https://app.graphite.dev/github/pr/llvm/llvm-project/132103?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/132103?utm_source=stack-comment-view-in-graphite";
 target="_blank">(View in Graphite)
* **#132101** https://app.graphite.dev/github/pr/llvm/llvm-project/132101?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>
* **#131939** https://app.graphite.dev/github/pr/llvm/llvm-project/131939?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>
* **#131924** https://app.graphite.dev/github/pr/llvm/llvm-project/131924?utm_source=stack-comment-icon";
 target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite" 
width="10px" height="10px"/>
* **#131894** https://app.graphite.dev/github/pr/llvm/llvm-project/131894?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 https://graphite.dev?utm-source=stack-comment";>Graphite. Learn 
more about https://stacking.dev/?utm_source=stack-comment";>stacking.


https://github.com/llvm/llvm-project/pull/132103
___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From 4fba6cff9cc3dc5b2a8eeedb8de0fded9178fcb3 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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-tools-extra] [clang-doc][NFC] Remove unnecessary directory cleanup (PR #132101)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132101

>From df32792335aa51d040a536a7132bf7e9fadff558 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 20:58:15 +
Subject: [PATCH] [clang-doc][NFC] Remove unnecessary directory cleanup

The tests all remove the directory at test start, and it only prevents
inspecting the test artifacts to remove them at the end of the test run.
---
 .../test/clang-doc/single-file-public.cpp  | 10 --
 clang-tools-extra/test/clang-doc/single-file.cpp   | 10 --
 clang-tools-extra/test/clang-doc/test-path-abs.cpp |  6 +++---
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/clang-tools-extra/test/clang-doc/single-file-public.cpp 
b/clang-tools-extra/test/clang-doc/single-file-public.cpp
index 82e81749a1c52..060db05c6d992 100644
--- a/clang-tools-extra/test/clang-doc/single-file-public.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file-public.cpp
@@ -1,5 +1,4 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
@@ -7,7 +6,6 @@
 //   (which we don't know in advance). This checks the record file by searching
 //   for a name with a 40-char USR name.
 // RUN: find %t/docs -regex ".*/[0-9A-F]*.yaml" -exec cat {} ";" | FileCheck 
%s --check-prefix=CHECK
-// RUN: rm -rf %t
 
 class Record {
 private:
@@ -30,7 +28,7 @@ void Record::function_public() {}
 // CHECK-NEXT: Name: 'GlobalNamespace'
 // CHECK-NEXT: QualName: 'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT:   LineNumber:  12
+// CHECK-NEXT:   LineNumber:  10
 // CHECK-NEXT:   Filename:'{{.*}}'
 // CHECK-NEXT: TagType: Class
 // CHECK-NEXT: ChildFunctions:
@@ -45,10 +43,10 @@ void Record::function_public() {}
 // CHECK-NEXT: Name:'GlobalNamespace'
 // CHECK-NEXT: QualName:'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT: LineNumber:  22
+// CHECK-NEXT: LineNumber:  20
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: Location:
-// CHECK-NEXT:   - LineNumber:  17
+// CHECK-NEXT:   - LineNumber:  15
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: IsMethod:true
 // CHECK-NEXT: Parent:
diff --git a/clang-tools-extra/test/clang-doc/single-file.cpp 
b/clang-tools-extra/test/clang-doc/single-file.cpp
index 211afb3b45e52..bea434eb2ed9a 100644
--- a/clang-tools-extra/test/clang-doc/single-file.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file.cpp
@@ -1,10 +1,8 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
-// RUN: cat %t/docs/index.yaml | FileCheck %s --check-prefix=CHECK
-// RUN: rm -rf %t
+// RUN: FileCheck %s -input-file=%t/docs/index.yaml --check-prefix=CHECK
 
 void function(int x);
 
@@ -16,10 +14,10 @@ void function(int x) {}
 // CHECK-NEXT:   - USR: '{{([0-9A-F]{40})}}'
 // CHECK-NEXT:Name:'function'
 // CHECK-NEXT:DefLocation:
-// CHECK-NEXT:  LineNumber:  11
+// CHECK-NEXT:  LineNumber:  9
 // CHECK-NEXT:  Filename:'{{.*}}
 // CHECK-NEXT:Location:
-// CHECK-NEXT:  - LineNumber:  9
+// CHECK-NEXT:  - LineNumber:  7
 // CHECK-NEXT:Filename:'{{.*}}'
 // CHECK-NEXT:Params:
 // CHECK-NEXT:  - Type:
diff --git a/clang-tools-extra/test/clang-doc/test-path-abs.cpp 
b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
index f6cce95bbea0c..292a2a3b5474d 100644
--- a/clang-tools-extra/test/clang-doc/test-path-abs.cpp
+++ b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
@@ -1,6 +1,6 @@
-// RUN: rm -rf %t && mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: clang-doc --format=html --executor=standalone %s --output=%t
 // RUN: FileCheck %s -input-file=%t/index_json.js  -check-prefix=JSON-INDEX
-// RUN: rm -rf %t
 
-// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
\ No newline at end of file
+// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
+

___
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-tools-extra] [clang-doc][NFC] Remove unnecessary directory cleanup (PR #132101)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132101

>From df32792335aa51d040a536a7132bf7e9fadff558 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 20:58:15 +
Subject: [PATCH] [clang-doc][NFC] Remove unnecessary directory cleanup

The tests all remove the directory at test start, and it only prevents
inspecting the test artifacts to remove them at the end of the test run.
---
 .../test/clang-doc/single-file-public.cpp  | 10 --
 clang-tools-extra/test/clang-doc/single-file.cpp   | 10 --
 clang-tools-extra/test/clang-doc/test-path-abs.cpp |  6 +++---
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/clang-tools-extra/test/clang-doc/single-file-public.cpp 
b/clang-tools-extra/test/clang-doc/single-file-public.cpp
index 82e81749a1c52..060db05c6d992 100644
--- a/clang-tools-extra/test/clang-doc/single-file-public.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file-public.cpp
@@ -1,5 +1,4 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
@@ -7,7 +6,6 @@
 //   (which we don't know in advance). This checks the record file by searching
 //   for a name with a 40-char USR name.
 // RUN: find %t/docs -regex ".*/[0-9A-F]*.yaml" -exec cat {} ";" | FileCheck 
%s --check-prefix=CHECK
-// RUN: rm -rf %t
 
 class Record {
 private:
@@ -30,7 +28,7 @@ void Record::function_public() {}
 // CHECK-NEXT: Name: 'GlobalNamespace'
 // CHECK-NEXT: QualName: 'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT:   LineNumber:  12
+// CHECK-NEXT:   LineNumber:  10
 // CHECK-NEXT:   Filename:'{{.*}}'
 // CHECK-NEXT: TagType: Class
 // CHECK-NEXT: ChildFunctions:
@@ -45,10 +43,10 @@ void Record::function_public() {}
 // CHECK-NEXT: Name:'GlobalNamespace'
 // CHECK-NEXT: QualName:'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT: LineNumber:  22
+// CHECK-NEXT: LineNumber:  20
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: Location:
-// CHECK-NEXT:   - LineNumber:  17
+// CHECK-NEXT:   - LineNumber:  15
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: IsMethod:true
 // CHECK-NEXT: Parent:
diff --git a/clang-tools-extra/test/clang-doc/single-file.cpp 
b/clang-tools-extra/test/clang-doc/single-file.cpp
index 211afb3b45e52..bea434eb2ed9a 100644
--- a/clang-tools-extra/test/clang-doc/single-file.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file.cpp
@@ -1,10 +1,8 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
-// RUN: cat %t/docs/index.yaml | FileCheck %s --check-prefix=CHECK
-// RUN: rm -rf %t
+// RUN: FileCheck %s -input-file=%t/docs/index.yaml --check-prefix=CHECK
 
 void function(int x);
 
@@ -16,10 +14,10 @@ void function(int x) {}
 // CHECK-NEXT:   - USR: '{{([0-9A-F]{40})}}'
 // CHECK-NEXT:Name:'function'
 // CHECK-NEXT:DefLocation:
-// CHECK-NEXT:  LineNumber:  11
+// CHECK-NEXT:  LineNumber:  9
 // CHECK-NEXT:  Filename:'{{.*}}
 // CHECK-NEXT:Location:
-// CHECK-NEXT:  - LineNumber:  9
+// CHECK-NEXT:  - LineNumber:  7
 // CHECK-NEXT:Filename:'{{.*}}'
 // CHECK-NEXT:Params:
 // CHECK-NEXT:  - Type:
diff --git a/clang-tools-extra/test/clang-doc/test-path-abs.cpp 
b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
index f6cce95bbea0c..292a2a3b5474d 100644
--- a/clang-tools-extra/test/clang-doc/test-path-abs.cpp
+++ b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
@@ -1,6 +1,6 @@
-// RUN: rm -rf %t && mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: clang-doc --format=html --executor=standalone %s --output=%t
 // RUN: FileCheck %s -input-file=%t/index_json.js  -check-prefix=JSON-INDEX
-// RUN: rm -rf %t
 
-// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
\ No newline at end of file
+// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
+

___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From 9293b4ce688b5e420e31e6b442be2f41233d2e1d Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From 9293b4ce688b5e420e31e6b442be2f41233d2e1d Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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] 2f37c9e - Revert "[Coverage] Fix region termination for GNU statement expressions (#130…"

2025-03-19 Thread via llvm-branch-commits


Author: Justin Cady
Date: 2025-03-19T16:45:26-04:00
New Revision: 2f37c9ec685b8ba82fdc3bd8387ce59b3f8a77dc

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

LOG: Revert "[Coverage] Fix region termination for GNU statement expressions 
(#130…"

This reverts commit 0827e3aae6eb69c2a6fa842ffa780881feb45b5d.

Added: 


Modified: 
clang/lib/CodeGen/CoverageMappingGen.cpp
clang/test/CoverageMapping/terminate-statements.cpp

Removed: 
compiler-rt/test/profile/Linux/coverage-statement-expression.cpp



diff  --git a/clang/lib/CodeGen/CoverageMappingGen.cpp 
b/clang/lib/CodeGen/CoverageMappingGen.cpp
index 73811d15979d5..f09157771d2b5 100644
--- a/clang/lib/CodeGen/CoverageMappingGen.cpp
+++ b/clang/lib/CodeGen/CoverageMappingGen.cpp
@@ -1505,14 +1505,6 @@ struct CounterCoverageMappingBuilder
 handleFileExit(getEnd(S));
   }
 
-  void VisitStmtExpr(const StmtExpr *E) {
-Visit(E->getSubStmt());
-// Any region termination (such as a noreturn CallExpr) within the 
statement
-// expression has been handled by visiting the sub-statement. The visitor
-// cannot be at a terminate statement leaving the statement expression.
-HasTerminateStmt = false;
-  }
-
   void VisitDecl(const Decl *D) {
 Stmt *Body = D->getBody();
 

diff  --git a/clang/test/CoverageMapping/terminate-statements.cpp 
b/clang/test/CoverageMapping/terminate-statements.cpp
index 3f8e43f0fbcb6..0067185fee8e6 100644
--- a/clang/test/CoverageMapping/terminate-statements.cpp
+++ b/clang/test/CoverageMapping/terminate-statements.cpp
@@ -346,12 +346,6 @@ int elsecondnoret(void) {
   return 0;
 }
 
-// CHECK-LABEL: _Z18statementexprnoretb
-int statementexprnoret(bool crash) {
-  int rc = ({ if (crash) abort(); 0; }); // CHECK: File 0, 351:35 -> 352:12 = 
(#0 - #1)
-  return rc; // CHECK-NOT: Gap
-}
-
 int main() {
   foo(0);
   foo(1);
@@ -374,6 +368,5 @@ int main() {
   ornoret();
   abstractcondnoret();
   elsecondnoret();
-  statementexprnoret(false);
   return 0;
 }

diff  --git a/compiler-rt/test/profile/Linux/coverage-statement-expression.cpp 
b/compiler-rt/test/profile/Linux/coverage-statement-expression.cpp
deleted file mode 100644
index 7c76555e3300b..0
--- a/compiler-rt/test/profile/Linux/coverage-statement-expression.cpp
+++ /dev/null
@@ -1,21 +0,0 @@
-// RUN: %clangxx_profgen -std=gnu++17 -fuse-ld=lld -fcoverage-mapping -o %t %s
-// RUN: env LLVM_PROFILE_FILE=%t.profraw %run %t
-// RUN: llvm-profdata merge -o %t.profdata %t.profraw
-// RUN: llvm-cov show %t -instr-profile=%t.profdata 2>&1 | FileCheck %s
-
-#include 
-
-// clang-format off
-__attribute__ ((__noreturn__))
-void foo(void) { while (1); }   // CHECK:  [[@LINE]]| 0|void 
foo(void)
-_Noreturn void bar(void) { while (1); } // CHECK:  [[@LINE]]| 
0|_Noreturn void bar(void)
-// CHECK:  [[@LINE]]|  |
-int main(int argc, char **argv) {   // CHECK:  [[@LINE]]| 1|int 
main(
-  int rc = ({ if (argc > 3) foo(); 0; });   // CHECK:  [[@LINE]]| 1|  int 
rc =
-  printf("coverage after foo is present\n");// CHECK:  [[@LINE]]| 1|  
printf(
-// CHECK:  [[@LINE]]|  |
-  int rc2 = ({ if (argc > 3) bar(); 0; });  // CHECK:  [[@LINE]]| 1|  int 
rc2 =
-  printf("coverage after bar is present\n");// CHECK:  [[@LINE]]| 1|  
printf(
-  return rc + rc2;  // CHECK:  [[@LINE]]| 1|  
return rc
-}   // CHECK:  [[@LINE]]| 1|}
-// clang-format on



___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From 4fba6cff9cc3dc5b2a8eeedb8de0fded9178fcb3 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From f50f1a7bac5c0a91fb8280d4ee90139691f07f95 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132103

>From f50f1a7bac5c0a91fb8280d4ee90139691f07f95 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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-tools-extra] [clang-doc][NFC] Remove unnecessary directory cleanup (PR #132101)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132101

>From c857982fa9162b37e34099bf20332cc0b22286ed Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 20:58:15 +
Subject: [PATCH] [clang-doc][NFC] Remove unnecessary directory cleanup

The tests all remove the directory at test start, and it only prevents
inspecting the test artifacts to remove them at the end of the test run.
---
 .../test/clang-doc/single-file-public.cpp  | 10 --
 clang-tools-extra/test/clang-doc/single-file.cpp   | 10 --
 clang-tools-extra/test/clang-doc/test-path-abs.cpp |  6 +++---
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/clang-tools-extra/test/clang-doc/single-file-public.cpp 
b/clang-tools-extra/test/clang-doc/single-file-public.cpp
index 82e81749a1c52..060db05c6d992 100644
--- a/clang-tools-extra/test/clang-doc/single-file-public.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file-public.cpp
@@ -1,5 +1,4 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
@@ -7,7 +6,6 @@
 //   (which we don't know in advance). This checks the record file by searching
 //   for a name with a 40-char USR name.
 // RUN: find %t/docs -regex ".*/[0-9A-F]*.yaml" -exec cat {} ";" | FileCheck 
%s --check-prefix=CHECK
-// RUN: rm -rf %t
 
 class Record {
 private:
@@ -30,7 +28,7 @@ void Record::function_public() {}
 // CHECK-NEXT: Name: 'GlobalNamespace'
 // CHECK-NEXT: QualName: 'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT:   LineNumber:  12
+// CHECK-NEXT:   LineNumber:  10
 // CHECK-NEXT:   Filename:'{{.*}}'
 // CHECK-NEXT: TagType: Class
 // CHECK-NEXT: ChildFunctions:
@@ -45,10 +43,10 @@ void Record::function_public() {}
 // CHECK-NEXT: Name:'GlobalNamespace'
 // CHECK-NEXT: QualName:'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT: LineNumber:  22
+// CHECK-NEXT: LineNumber:  20
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: Location:
-// CHECK-NEXT:   - LineNumber:  17
+// CHECK-NEXT:   - LineNumber:  15
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: IsMethod:true
 // CHECK-NEXT: Parent:
diff --git a/clang-tools-extra/test/clang-doc/single-file.cpp 
b/clang-tools-extra/test/clang-doc/single-file.cpp
index 211afb3b45e52..bea434eb2ed9a 100644
--- a/clang-tools-extra/test/clang-doc/single-file.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file.cpp
@@ -1,10 +1,8 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
-// RUN: cat %t/docs/index.yaml | FileCheck %s --check-prefix=CHECK
-// RUN: rm -rf %t
+// RUN: FileCheck %s -input-file=%t/docs/index.yaml --check-prefix=CHECK
 
 void function(int x);
 
@@ -16,10 +14,10 @@ void function(int x) {}
 // CHECK-NEXT:   - USR: '{{([0-9A-F]{40})}}'
 // CHECK-NEXT:Name:'function'
 // CHECK-NEXT:DefLocation:
-// CHECK-NEXT:  LineNumber:  11
+// CHECK-NEXT:  LineNumber:  9
 // CHECK-NEXT:  Filename:'{{.*}}
 // CHECK-NEXT:Location:
-// CHECK-NEXT:  - LineNumber:  9
+// CHECK-NEXT:  - LineNumber:  7
 // CHECK-NEXT:Filename:'{{.*}}'
 // CHECK-NEXT:Params:
 // CHECK-NEXT:  - Type:
diff --git a/clang-tools-extra/test/clang-doc/test-path-abs.cpp 
b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
index f6cce95bbea0c..292a2a3b5474d 100644
--- a/clang-tools-extra/test/clang-doc/test-path-abs.cpp
+++ b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
@@ -1,6 +1,6 @@
-// RUN: rm -rf %t && mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: clang-doc --format=html --executor=standalone %s --output=%t
 // RUN: FileCheck %s -input-file=%t/index_json.js  -check-prefix=JSON-INDEX
-// RUN: rm -rf %t
 
-// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
\ No newline at end of file
+// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
+

___
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-tools-extra] [clang-doc][NFC] Remove unnecessary directory cleanup (PR #132101)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/132101

>From c857982fa9162b37e34099bf20332cc0b22286ed Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 20:58:15 +
Subject: [PATCH] [clang-doc][NFC] Remove unnecessary directory cleanup

The tests all remove the directory at test start, and it only prevents
inspecting the test artifacts to remove them at the end of the test run.
---
 .../test/clang-doc/single-file-public.cpp  | 10 --
 clang-tools-extra/test/clang-doc/single-file.cpp   | 10 --
 clang-tools-extra/test/clang-doc/test-path-abs.cpp |  6 +++---
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/clang-tools-extra/test/clang-doc/single-file-public.cpp 
b/clang-tools-extra/test/clang-doc/single-file-public.cpp
index 82e81749a1c52..060db05c6d992 100644
--- a/clang-tools-extra/test/clang-doc/single-file-public.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file-public.cpp
@@ -1,5 +1,4 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
@@ -7,7 +6,6 @@
 //   (which we don't know in advance). This checks the record file by searching
 //   for a name with a 40-char USR name.
 // RUN: find %t/docs -regex ".*/[0-9A-F]*.yaml" -exec cat {} ";" | FileCheck 
%s --check-prefix=CHECK
-// RUN: rm -rf %t
 
 class Record {
 private:
@@ -30,7 +28,7 @@ void Record::function_public() {}
 // CHECK-NEXT: Name: 'GlobalNamespace'
 // CHECK-NEXT: QualName: 'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT:   LineNumber:  12
+// CHECK-NEXT:   LineNumber:  10
 // CHECK-NEXT:   Filename:'{{.*}}'
 // CHECK-NEXT: TagType: Class
 // CHECK-NEXT: ChildFunctions:
@@ -45,10 +43,10 @@ void Record::function_public() {}
 // CHECK-NEXT: Name:'GlobalNamespace'
 // CHECK-NEXT: QualName:'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT: LineNumber:  22
+// CHECK-NEXT: LineNumber:  20
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: Location:
-// CHECK-NEXT:   - LineNumber:  17
+// CHECK-NEXT:   - LineNumber:  15
 // CHECK-NEXT: Filename:'{{.*}}'
 // CHECK-NEXT: IsMethod:true
 // CHECK-NEXT: Parent:
diff --git a/clang-tools-extra/test/clang-doc/single-file.cpp 
b/clang-tools-extra/test/clang-doc/single-file.cpp
index 211afb3b45e52..bea434eb2ed9a 100644
--- a/clang-tools-extra/test/clang-doc/single-file.cpp
+++ b/clang-tools-extra/test/clang-doc/single-file.cpp
@@ -1,10 +1,8 @@
-// RUN: rm -rf %t
-// RUN: mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
-// RUN: cat %t/docs/index.yaml | FileCheck %s --check-prefix=CHECK
-// RUN: rm -rf %t
+// RUN: FileCheck %s -input-file=%t/docs/index.yaml --check-prefix=CHECK
 
 void function(int x);
 
@@ -16,10 +14,10 @@ void function(int x) {}
 // CHECK-NEXT:   - USR: '{{([0-9A-F]{40})}}'
 // CHECK-NEXT:Name:'function'
 // CHECK-NEXT:DefLocation:
-// CHECK-NEXT:  LineNumber:  11
+// CHECK-NEXT:  LineNumber:  9
 // CHECK-NEXT:  Filename:'{{.*}}
 // CHECK-NEXT:Location:
-// CHECK-NEXT:  - LineNumber:  9
+// CHECK-NEXT:  - LineNumber:  7
 // CHECK-NEXT:Filename:'{{.*}}'
 // CHECK-NEXT:Params:
 // CHECK-NEXT:  - Type:
diff --git a/clang-tools-extra/test/clang-doc/test-path-abs.cpp 
b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
index f6cce95bbea0c..292a2a3b5474d 100644
--- a/clang-tools-extra/test/clang-doc/test-path-abs.cpp
+++ b/clang-tools-extra/test/clang-doc/test-path-abs.cpp
@@ -1,6 +1,6 @@
-// RUN: rm -rf %t && mkdir %t
+// RUN: rm -rf %t && mkdir -p %t
 // RUN: clang-doc --format=html --executor=standalone %s --output=%t
 // RUN: FileCheck %s -input-file=%t/index_json.js  -check-prefix=JSON-INDEX
-// RUN: rm -rf %t
 
-// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
\ No newline at end of file
+// JSON-INDEX: var RootPath = "{{.*}}test-path-abs.cpp.tmp";
+

___
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-tools-extra] [clang-doc] Avoid deref of invalid std::optional (PR #131939)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi updated 
https://github.com/llvm/llvm-project/pull/131939

>From ea338585014151fcc5806a1c39ad39e9cb35999a Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Tue, 18 Mar 2025 23:38:09 +
Subject: [PATCH] [clang-doc] Avoid deref of invalid std::optional

Since our existing guard is insufficient to prevent accessing the
std::optional when in an invalid state, guard the access with
`.value_or()`. This maintains the desired behavior, without running into
UB.

The new test should prevent regressions.

Fixes #131697
---
 clang-tools-extra/clang-doc/HTMLGenerator.cpp |  2 +-
 .../test/clang-doc/DR-131697.cpp  | 22 +++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 clang-tools-extra/test/clang-doc/DR-131697.cpp

diff --git a/clang-tools-extra/clang-doc/HTMLGenerator.cpp 
b/clang-tools-extra/clang-doc/HTMLGenerator.cpp
index 18a0de826630c..a8404479569f9 100644
--- a/clang-tools-extra/clang-doc/HTMLGenerator.cpp
+++ b/clang-tools-extra/clang-doc/HTMLGenerator.cpp
@@ -498,7 +498,7 @@ writeFileDefinition(const Location &L,
 return std::make_unique(
 HTMLTag::TAG_P, "Defined at line " + std::to_string(L.LineNumber) +
 " of file " + L.Filename);
-  SmallString<128> FileURL(*RepositoryUrl);
+  SmallString<128> FileURL(RepositoryUrl.value_or(""));
   llvm::sys::path::append(
   FileURL, llvm::sys::path::Style::posix,
   // If we're on Windows, the file name will be in the wrong format, and
diff --git a/clang-tools-extra/test/clang-doc/DR-131697.cpp 
b/clang-tools-extra/test/clang-doc/DR-131697.cpp
new file mode 100644
index 0..50556ecd2635b
--- /dev/null
+++ b/clang-tools-extra/test/clang-doc/DR-131697.cpp
@@ -0,0 +1,22 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: split-file %s %t
+// RUN: clang-doc -format=html %t/compile-commands.json %t/main.cpp
+
+//--- main.cpp
+
+class Foo {
+  void getFoo();
+};
+
+int main() {
+  return 0;
+}
+
+//--- compile-commands.json
+[
+{
+  "directory": "foo",
+  "file":"main.cpp",
+  "command":"clang main.cpp -c"
+}
+]

___
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] [clang-tools-extra] [clang][HeuristicResolver] Default argument heuristic for template parameters (PR #131074)

2025-03-19 Thread Younan Zhang via llvm-branch-commits



@@ -125,6 +126,20 @@ TagDecl 
*HeuristicResolverImpl::resolveTypeToTagDecl(QualType QT) {
   if (!T)
 return nullptr;
 
+  // If T is the type of a template parameter, we can't get a useful TagDecl
+  // out of it. However, if the template parameter has a default argument,
+  // as a heuristic we can replace T with the default argument type.
+  if (const auto *TTPT = dyn_cast(T)) {
+if (const auto *TTPD = TTPT->getDecl()) {
+  if (TTPD->hasDefaultArgument()) {
+const auto &DefaultArg = TTPD->getDefaultArgument().getArgument();
+if (DefaultArg.getKind() == TemplateArgument::Type) {
+  T = DefaultArg.getAsType().getTypePtrOrNull();

zyn0217 wrote:

Do we traverse the default arguments recursively? I'm thinking a case like
```cpp
template 
void bar(T t) {
  t.foo(); // Can we resolve it to Waldo::foo()?
}
```

Also there are some usages for template template parameters, e.g.
```cpp
template  class V = std::vector>
void foo(V) {
  V.push_back(42); // Would be great to resolve it to std::vector<>::push_back()
}
```

However it depends on the implementation complexity - there's no necessity to 
handle these in this patch

https://github.com/llvm/llvm-project/pull/131074
___
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] [clang-tools-extra] [clang][HeuristicResolver] Default argument heuristic for template parameters (PR #131074)

2025-03-19 Thread Younan Zhang via llvm-branch-commits


https://github.com/zyn0217 edited 
https://github.com/llvm/llvm-project/pull/131074
___
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-tools-extra] [clang-doc] Correct improper file paths in HTML output (PR #132103)

2025-03-19 Thread Paul Kirth via llvm-branch-commits


https://github.com/ilovepi created 
https://github.com/llvm/llvm-project/pull/132103

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.

>From 6182de900b039f86b564ecf8b74fce8f07317d28 Mon Sep 17 00:00:00 2001
From: Paul Kirth 
Date: Wed, 19 Mar 2025 21:07:22 +
Subject: [PATCH] [clang-doc] Correct improper file paths in HTML output

In index.js the logic of the ternary operator was backwards, preventing
us from generating the correct file paths, or relative paths in the HTML
output.
---
 clang-tools-extra/clang-doc/assets/index.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/clang-tools-extra/clang-doc/assets/index.js 
b/clang-tools-extra/clang-doc/assets/index.js
index 6a223de66f84a..58a92f049f19f 100644
--- a/clang-tools-extra/clang-doc/assets/index.js
+++ b/clang-tools-extra/clang-doc/assets/index.js
@@ -2,8 +2,8 @@ function genLink(Ref) {
   // we treat the file paths different depending on if we're
   // serving via a http server or viewing from a local
   var Path = window.location.protocol.startsWith("file") ?
-  `${window.location.protocol}//${window.location.host}/${Ref.Path}` :
-  `${window.location.protocol}//${RootPath}/${Ref.Path}`;
+  `${window.location.protocol}//${RootPath}/${Ref.Path}` :
+  `${window.location.protocol}//${window.location.host}/${Ref.Path}`;
   if (Ref.RefType === "namespace") {
 Path = `${Path}/index.html`
   } else if (Ref.Path === "") {

___
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/20.x: [HEXAGON] Add support to lower "FREEZE a half(f16)" instruction on Hexagon and fix the isel-buildvector-v2f16.ll assertion (#130977) (PR #132138)

2025-03-19 Thread via llvm-branch-commits


llvmbot wrote:

@androm3da What do you think about merging this PR to the release branch?

https://github.com/llvm/llvm-project/pull/132138
___
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/20.x: [HEXAGON] Add support to lower "FREEZE a half(f16)" instruction on Hexagon and fix the isel-buildvector-v2f16.ll assertion (#130977) (PR #132138)

2025-03-19 Thread via llvm-branch-commits


llvmbot wrote:




@llvm/pr-subscribers-backend-hexagon

Author: None (llvmbot)


Changes

Backport 9c65e6ac115a

Requested by: @androm3da

---
Full diff: https://github.com/llvm/llvm-project/pull/132138.diff


3 Files Affected:

- (modified) llvm/lib/Target/Hexagon/HexagonISelLowering.h (+1) 
- (modified) llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp (+11-11) 
- (added) llvm/test/CodeGen/Hexagon/fp16-promote.ll (+44) 


``diff
diff --git a/llvm/lib/Target/Hexagon/HexagonISelLowering.h 
b/llvm/lib/Target/Hexagon/HexagonISelLowering.h
index aaa9c65c1e07e..4df88b3a8abd7 100644
--- a/llvm/lib/Target/Hexagon/HexagonISelLowering.h
+++ b/llvm/lib/Target/Hexagon/HexagonISelLowering.h
@@ -362,6 +362,7 @@ class HexagonTargetLowering : public TargetLowering {
   shouldExpandAtomicRMWInIR(AtomicRMWInst *AI) const override {
 return AtomicExpansionKind::LLSC;
   }
+  bool softPromoteHalfType() const override { return true; }
 
 private:
   void initializeHVXLowering();
diff --git a/llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp 
b/llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp
index 1a19e81a68f08..a7eb20a3e5ff9 100644
--- a/llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp
+++ b/llvm/lib/Target/Hexagon/HexagonISelLoweringHVX.cpp
@@ -1618,17 +1618,6 @@ HexagonTargetLowering::LowerHvxBuildVector(SDValue Op, 
SelectionDAG &DAG)
   for (unsigned i = 0; i != Size; ++i)
 Ops.push_back(Op.getOperand(i));
 
-  // First, split the BUILD_VECTOR for vector pairs. We could generate
-  // some pairs directly (via splat), but splats should be generated
-  // by the combiner prior to getting here.
-  if (VecTy.getSizeInBits() == 16*Subtarget.getVectorLength()) {
-ArrayRef A(Ops);
-MVT SingleTy = typeSplit(VecTy).first;
-SDValue V0 = buildHvxVectorReg(A.take_front(Size/2), dl, SingleTy, DAG);
-SDValue V1 = buildHvxVectorReg(A.drop_front(Size/2), dl, SingleTy, DAG);
-return DAG.getNode(ISD::CONCAT_VECTORS, dl, VecTy, V0, V1);
-  }
-
   if (VecTy.getVectorElementType() == MVT::i1)
 return buildHvxVectorPred(Ops, dl, VecTy, DAG);
 
@@ -1645,6 +1634,17 @@ HexagonTargetLowering::LowerHvxBuildVector(SDValue Op, 
SelectionDAG &DAG)
 return DAG.getBitcast(tyVector(VecTy, MVT::f16), T0);
   }
 
+  // First, split the BUILD_VECTOR for vector pairs. We could generate
+  // some pairs directly (via splat), but splats should be generated
+  // by the combiner prior to getting here.
+  if (VecTy.getSizeInBits() == 16 * Subtarget.getVectorLength()) {
+ArrayRef A(Ops);
+MVT SingleTy = typeSplit(VecTy).first;
+SDValue V0 = buildHvxVectorReg(A.take_front(Size / 2), dl, SingleTy, DAG);
+SDValue V1 = buildHvxVectorReg(A.drop_front(Size / 2), dl, SingleTy, DAG);
+return DAG.getNode(ISD::CONCAT_VECTORS, dl, VecTy, V0, V1);
+  }
+
   return buildHvxVectorReg(Ops, dl, VecTy, DAG);
 }
 
diff --git a/llvm/test/CodeGen/Hexagon/fp16-promote.ll 
b/llvm/test/CodeGen/Hexagon/fp16-promote.ll
new file mode 100644
index 0..1ef0a133ce30a
--- /dev/null
+++ b/llvm/test/CodeGen/Hexagon/fp16-promote.ll
@@ -0,0 +1,44 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -march=hexagon  < %s | FileCheck %s
+
+define half @freeze_half_undef() nounwind {
+; CHECK-LABEL: freeze_half_undef:
+; CHECK:   // %bb.0:
+; CHECK-NEXT:{
+; CHECK-NEXT: call __truncsfhf2
+; CHECK-NEXT: r0 = #0
+; CHECK-NEXT: allocframe(#0)
+; CHECK-NEXT:}
+; CHECK-NEXT:{
+; CHECK-NEXT: call __extendhfsf2
+; CHECK-NEXT:}
+; CHECK-NEXT:{
+; CHECK-NEXT: call __truncsfhf2
+; CHECK-NEXT: r0 = sfadd(r0,r0)
+; CHECK-NEXT:}
+; CHECK-NEXT:{
+; CHECK-NEXT: r31:30 = dealloc_return(r30):raw
+; CHECK-NEXT:}
+  %y1 = freeze half undef
+  %t1 = fadd half %y1, %y1
+  ret half %t1
+}
+
+define half @freeze_half_poison(half %maybe.poison) {
+; CHECK-LABEL: freeze_half_poison:
+; CHECK:  // %bb.0:
+; CHECK:{
+; CHECK-NEXT: call __extendhfsf2
+; CHECK-NEXT: allocframe(r29,#0):raw
+; CHECK-NEXT:}
+; CHECK-NEXT:{
+; CHECK-NEXT: call __truncsfhf2
+; CHECK-NEXT: r0 = sfadd(r0,r0)
+; CHECK-NEXT:}
+; CHECK-NEXT:{
+; CHECK-NEXT: r31:30 = dealloc_return(r30):raw
+; CHECK-NEXT:}
+  %y1 = freeze half %maybe.poison
+  %t1 = fadd half %y1, %y1
+  ret half %t1
+}

``




https://github.com/llvm/llvm-project/pull/132138
___
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] Backport: [clang] fix matching of nested template template parameters (PR #130950)

2025-03-19 Thread Matheus Izvekov via llvm-branch-commits


mizvekov wrote:

Gentle Ping

https://github.com/llvm/llvm-project/pull/130950
___
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] 16e0ae5 - Revert "[flang][openmp] Adds Parser and Semantic Support for Interop Construc…"

2025-03-19 Thread via llvm-branch-commits


Author: Kiran Chandramohan
Date: 2025-03-19T11:13:10Z
New Revision: 16e0ae5e9a6a507cdf39a45823ac0df18bb7d946

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

LOG: Revert "[flang][openmp] Adds Parser and Semantic Support for Interop 
Construc…"

This reverts commit ee8a759bfb4772dea7459f4ecbd83bc2be5ee68b.

Added: 


Modified: 
flang/examples/FeatureList/FeatureList.cpp
flang/include/flang/Parser/dump-parse-tree.h
flang/include/flang/Parser/parse-tree.h
flang/include/flang/Semantics/openmp-modifiers.h
flang/lib/Lower/OpenMP/OpenMP.cpp
flang/lib/Parser/openmp-parsers.cpp
flang/lib/Parser/unparse.cpp
flang/lib/Semantics/check-omp-structure.cpp
flang/lib/Semantics/check-omp-structure.h
flang/lib/Semantics/openmp-modifiers.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 
flang/test/Lower/OpenMP/Todo/inteorp-construct.f90
flang/test/Parser/OpenMP/interop-construct.f90
flang/test/Semantics/OpenMP/interop-construct.f90



diff  --git a/flang/examples/FeatureList/FeatureList.cpp 
b/flang/examples/FeatureList/FeatureList.cpp
index e34f103a1df04..a1a908820e39c 100644
--- a/flang/examples/FeatureList/FeatureList.cpp
+++ b/flang/examples/FeatureList/FeatureList.cpp
@@ -522,13 +522,6 @@ struct NodeVisitor {
   READ_FEATURE(OmpScheduleClause)
   READ_FEATURE(OmpScheduleClause::Kind)
   READ_FEATURE(OmpScheduleClause::Modifier)
-  READ_FEATURE(OmpInteropRuntimeIdentifier)
-  READ_FEATURE(OmpInteropPreference)
-  READ_FEATURE(OmpInteropType)
-  READ_FEATURE(OmpInteropType::Value)
-  READ_FEATURE(OmpInitClause)
-  READ_FEATURE(OmpInitClause::Modifier)
-  READ_FEATURE(OmpUseClause)
   READ_FEATURE(OmpDeviceModifier)
   READ_FEATURE(OmpDeviceClause)
   READ_FEATURE(OmpDeviceClause::Modifier)
@@ -549,7 +542,6 @@ struct NodeVisitor {
   READ_FEATURE(OpenACCConstruct)
   READ_FEATURE(OpenACCDeclarativeConstruct)
   READ_FEATURE(OpenACCLoopConstruct)
-  READ_FEATURE(OpenMPInteropConstruct)
   READ_FEATURE(OpenACCRoutineConstruct)
   READ_FEATURE(OpenACCStandaloneDeclarativeConstruct)
   READ_FEATURE(OpenACCStandaloneConstruct)

diff  --git a/flang/include/flang/Parser/dump-parse-tree.h 
b/flang/include/flang/Parser/dump-parse-tree.h
index 8f6fd868feaf0..25fcc843f3732 100644
--- a/flang/include/flang/Parser/dump-parse-tree.h
+++ b/flang/include/flang/Parser/dump-parse-tree.h
@@ -656,13 +656,6 @@ class ParseTreeDumper {
   NODE_ENUM(OmpDeviceModifier, Value)
   NODE(parser, OmpDeviceTypeClause)
   NODE_ENUM(OmpDeviceTypeClause, DeviceTypeDescription)
-  NODE(parser, OmpInteropRuntimeIdentifier)
-  NODE(parser, OmpInteropPreference)
-  NODE(parser, OmpInteropType)
-  NODE_ENUM(OmpInteropType, Value)
-  NODE(parser, OmpInitClause)
-  NODE(OmpInitClause, Modifier)
-  NODE(parser, OmpUseClause)
   NODE(parser, OmpUpdateClause)
   NODE(parser, OmpChunkModifier)
   NODE_ENUM(OmpChunkModifier, Value)
@@ -682,7 +675,6 @@ class ParseTreeDumper {
   NODE(parser, OpenACCDeclarativeConstruct)
   NODE(parser, OpenACCEndConstruct)
   NODE(parser, OpenACCLoopConstruct)
-  NODE(parser, OpenMPInteropConstruct)
   NODE(parser, OpenACCRoutineConstruct)
   NODE(parser, OpenACCStandaloneDeclarativeConstruct)
   NODE(parser, OpenACCStandaloneConstruct)

diff  --git a/flang/include/flang/Parser/parse-tree.h 
b/flang/include/flang/Parser/parse-tree.h
index 371d7653b3b34..1b1d4125464e3 100644
--- a/flang/include/flang/Parser/parse-tree.h
+++ b/flang/include/flang/Parser/parse-tree.h
@@ -3824,33 +3824,6 @@ struct OmpExpectation {
   WRAPPER_CLASS_BOILERPLATE(OmpExpectation, Value);
 };
 
-// REF: [5.1:217-220], [5.2:293-294]
-//
-// OmpInteropRuntimeIdentifier ->   // since 5.2
-// CharLiteralConstant || ScalarIntConstantExpr
-struct OmpInteropRuntimeIdentifier {
-  UNION_CLASS_BOILERPLATE(OmpInteropRuntimeIdentifier);
-  std::variant u;
-};
-
-// REF: [5.1:217-220], [5.2:293-294]
-//
-// OmpInteropPreference ->  // since 5.2
-// ([OmpRuntimeIdentifier, ...])
-struct OmpInteropPreference {
-  WRAPPER_CLASS_BOILERPLATE(
-  OmpInteropPreference, std::list);
-};
-
-// REF: [5.1:217-220], [5.2:293-294]
-//
-// InteropType -> target || targetsync  // since 5.2
-// There can be at most only two interop-type.
-struct OmpInteropType {
-  ENUM_CLASS(Value, Target, TargetSync)
-  WRAPPER_CLASS_BOILERPLATE(OmpInteropType, Value);
-};
-
 // Ref: [5.0:47-49], [5.1:49-51], [5.2:67-69]
 //
 // iterator-modifier ->
@@ -4508,25 +4481,6 @@ struct OmpWhenClause {
   t;
 };
 
-// REF: [5.1:217-220], [5.2:293-294]
-//
-// init-clause -> INIT ([interop-modifier,] [interop-type,]
-//  interop-type: interop-var)
-// interop-modifier: prefer_type(preference-list)
-// interop-type: target, targetsync
-// interop-

[llvm-branch-commits] [clang] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (PR #131853)

2025-03-19 Thread Aaron Ballman via llvm-branch-commits



@@ -7567,9 +7567,13 @@ def warn_arith_conv_mixed_enum_types_cxx20 : Warning<
   "%sub{select_arith_conv_kind}0 "
   "different enumeration types%diff{ ($ and $)|}1,2 is deprecated">,
   InGroup;
-def err_conv_mixed_enum_types_cxx26 : Error<
+
+def err_conv_mixed_enum_types: Error <
   "invalid %sub{select_arith_conv_kind}0 "
   "different enumeration types%diff{ ($ and $)|}1,2">;
+def warn_conv_mixed_enum_types_cxx26 : Warning <
+  err_conv_mixed_enum_types.Summary>,
+  InGroup, DefaultError;

AaronBallman wrote:

I don't know of a reliable way to ensure the diagnostic is at the end of the 
list. I think putting it at the end of DiagnosticSemaKinds.td will suffice (we 
allocate diagnostic IDs in blocks based on the .td file they're in). However, 
I'm not certain that's a guarantee.

Perhaps we don't backport this?

https://github.com/llvm/llvm-project/pull/131853
___
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/20.x: [libcxx] Add a missing include for __bit_iterator (#127015) (PR #131382)

2025-03-19 Thread Louis Dionne via llvm-branch-commits


https://github.com/ldionne edited 
https://github.com/llvm/llvm-project/pull/131382
___
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] Support image_bvh8_intersect_ray instruction and intrinsic. (PR #130041)

2025-03-19 Thread Mariusz Sikora via llvm-branch-commits



@@ -1509,18 +1509,18 @@ multiclass MIMG_Gather 
 : MIMG_Gather;
 
-class MIMG_IntersectRay_Helper {
-  int num_addrs = !if(Is64, !if(IsA16, 9, 12), !if(IsA16, 8, 11));
+class MIMG_IntersectRay_Helper {
+  int num_addrs = !if(isBVH8, 11, !if(Is64, !if(IsA16, 9, 12), !if(IsA16, 8, 
11)));
   RegisterClass RegClass = MIMGAddrSize.RegClass;
   int VAddrDwords = !srl(RegClass.Size, 5);
 
   int GFX11PlusNSAAddrs = !if(IsA16, 4, 5);
   RegisterClass node_ptr_type = !if(Is64, VReg_64, VGPR_32);
   list GFX11PlusAddrTypes =
-!if(isDual, [VReg_64, VReg_64, VReg_96, VReg_96, VReg_64],
- !if(IsA16,
-  [node_ptr_type, VGPR_32, VReg_96, VReg_96],
-  [node_ptr_type, VGPR_32, VReg_96, VReg_96, VReg_96]));
+ !cond(!eq(isBVH8, 1) : [node_ptr_type, VReg_64, VReg_96, VReg_96, 
VGPR_32],
+   !eq(isDual, 1) : [node_ptr_type, VReg_64, VReg_96, VReg_96, 
VReg_64],
+   !eq(IsA16,  0) : [node_ptr_type, VGPR_32, VReg_96, VReg_96, 
VReg_96],
+   !eq(IsA16,  1) : [node_ptr_type, VGPR_32, VReg_96, VReg_96]);

mariusz-sikora-at-amd wrote:

Done, thanks

https://github.com/llvm/llvm-project/pull/130041
___
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] [Clang][Backport] Demote mixed enumeration arithmetic error to a warning (PR #131853)

2025-03-19 Thread via llvm-branch-commits


https://github.com/cor3ntin closed 
https://github.com/llvm/llvm-project/pull/131853
___
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] [clang-tools-extra] [clang] NFC: Clear some uses of MemberPointerType::getClass (PR #131965)

2025-03-19 Thread Erich Keane via llvm-branch-commits


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

Just did a spot-check, but the uses I saw all seemed reasonable.

There ARE a few cases I saw where it did a `cast` to `RecordType` then a 
`getDecl`, so this loses the assert, but I think that is still reasonable.

https://github.com/llvm/llvm-project/pull/131965
___
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] [llvm] release/20.x: [Hexagon] Set the default compilation target to V68 (#125239) (PR #128597)

2025-03-19 Thread Alex Rønne Petersen via llvm-branch-commits


alexrp wrote:

Given 20.1.1 was just released, is the plan still to get this one into 20.x? 
(Just asking to know whether we should make a corresponding change in Zig.)

https://github.com/llvm/llvm-project/pull/128597
___
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] [SDAG] Introduce inbounds flag for pointer arithmetic (PR #131862)

2025-03-19 Thread Eli Friedman via llvm-branch-commits


efriedma-quic wrote:

Saying "one side is inbounds of the other side" is basically useless, as far as 
I can tell, for almost any transform.

The other possibility you mentioned is that we say one side is a constant, the 
other is not, and the non-constant side must be a pointer?  That seems fragile. 
 The semantics of the add depend on the "syntactic" form of the operands, which 
could be rewritten.  Not really great.

Maybe we could consider adding "ISD::PTRADD"?  Lowers to ISD::ADD by default, 
but targets that want to do weird things with pointer arithmetic could do them.

One other concern, which applies to basically any formulation of this: Since 
SelectionDAG doesn't have a distinct pointer type, you can't tell whether the 
pointer operand was produced by an inttoptr.  So in some cases, you have an 
operation marked "inbounds", but it's ambiguous which object it's actually 
inbounds to.  This isn't really a problem at the moment because we do IR-level 
transforms that remove inttoptr anyway, but if we ever do resolve the IR-level 
issues, we should have some idea for how we propagate the fix to SelectionDAG.

https://github.com/llvm/llvm-project/pull/131862
___
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/20.x: [PowerPC] Support conversion between f16 and f128 (#130158) (PR #132049)

2025-03-19 Thread Trevor Gross via llvm-branch-commits


tgross35 wrote:

> @tgross35 What do you think about merging this PR to the release branch?

I'd be happy to have it but it's certainly not my call. @RolandF77 was the 
original reviewer.

https://github.com/llvm/llvm-project/pull/132049
___
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] [CUDA][HIP] fix virtual dtor host/device attr (PR #130126)

2025-03-19 Thread Yaxun Liu via llvm-branch-commits


yxsamliu wrote:

> @yxsamliu (or anyone else). If you would like to add a note about this fix in 
> the release notes (completely optional). Please reply to this comment with a 
> one or two sentence description of the fix. When you are done, please add the 
> release:note label to this PR.

Fixed an issue about implicit device attributes of virtual destructors which 
causes undefined symbols for CUDA/HIP programs which use std::string as class 
members with C++20 and MSVC.

https://github.com/llvm/llvm-project/pull/130126
___
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] [SPARC][MC] Add tests for VIS family instructions (PR #130967)

2025-03-19 Thread via llvm-branch-commits


koachan wrote:

Ping?

https://github.com/llvm/llvm-project/pull/130967
___
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] [clang-tools-extra] [clang][HeuristicResolver] Default argument heuristic for template parameters (PR #131074)

2025-03-19 Thread Haojian Wu via llvm-branch-commits



@@ -125,6 +126,20 @@ TagDecl 
*HeuristicResolverImpl::resolveTypeToTagDecl(QualType QT) {
   if (!T)
 return nullptr;
 
+  // If T is the type of a template parameter, we can't get a useful TagDecl
+  // out of it. However, if the template parameter has a default argument,
+  // as a heuristic we can replace T with the default argument type.
+  if (const auto *TTPT = dyn_cast(T)) {
+if (const auto *TTPD = TTPT->getDecl()) {
+  if (TTPD->hasDefaultArgument()) {
+const auto &DefaultArg = TTPD->getDefaultArgument().getArgument();
+if (DefaultArg.getKind() == TemplateArgument::Type) {
+  T = DefaultArg.getAsType().getTypePtrOrNull();

hokein wrote:

the code doesn't look safe -- `getTypePtrOrNull` could return a nullptr, then 
we have a null-reference on Line144. Move this new code block before line 126?

https://github.com/llvm/llvm-project/pull/131074
___
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] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

2025-03-19 Thread Alexander Richardson via llvm-branch-commits



@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
 
 .. _nointptrtype:
 
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
 
-Note: non-integral pointer types are a work in progress, and they should be
-considered experimental at this time.
+Note: non-integral/unstable pointer types are a work in progress, and they
+should be considered experimental at this time.
 
 LLVM IR optionally allows the frontend to denote pointers in certain address
-spaces as "non-integral" via the :ref:`datalayout string`.
-Non-integral pointer types represent pointers that have an *unspecified* 
bitwise
-representation; that is, the integral representation may be target dependent or
-unstable (not backed by a fixed integer).
+spaces as "non-integral" or "unstable" (or both "non-integral" and "unstable")
+via the :ref:`datalayout string`.
+
+The exact implications of these properties are target-specific, but the
+following IR semantics and restrictions to optimization passes apply:
+
+Unstable pointer representation
+^^^
+
+Pointers in this address space have an *unspecified* bitwise representation
+(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
+allowed to change in a target-specific way. For example, this could be a 
pointer
+type used with copying garbage collection where the garbage collector could
+update the pointer at any time in the collection sweep.
 
 ``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
 integral (i.e. normal) pointers in that they convert integers to and from
-corresponding pointer types, but there are additional implications to be
-aware of.  Because the bit-representation of a non-integral pointer may
-not be stable, two identical casts of the same operand may or may not
+corresponding pointer types, but there are additional implications to be aware
+of.
+
+For "unstable" pointer representations, the bit-representation of the pointer
+may not be stable, so two identical casts of the same operand may or may not
 return the same value.  Said differently, the conversion to or from the
-non-integral type depends on environmental state in an implementation
+"unstable" pointer type depends on environmental state in an implementation
 defined manner.
-
 If the frontend wishes to observe a *particular* value following a cast, the
 generated IR must fence with the underlying environment in an implementation
 defined manner. (In practice, this tends to require ``noinline`` routines for
 such operations.)
 
 From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
-non-integral types are analogous to ones on integral types with one
+"unstable" pointer types are analogous to ones on integral types with one
 key exception: the optimizer may not, in general, insert new dynamic
 occurrences of such casts.  If a new cast is inserted, the optimizer would
 need to either ensure that a) all possible values are valid, or b)
 appropriate fencing is inserted.  Since the appropriate fencing is
 implementation defined, the optimizer can't do the latter.  The former is
 challenging as many commonly expected properties, such as
-``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
+``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for "unstable" pointer types.
 Similar restrictions apply to intrinsics that might examine the pointer bits,
 such as :ref:`llvm.ptrmask`.
 
-The alignment information provided by the frontend for a non-integral pointer
+The alignment information provided by the frontend for an "unstable" pointer
 (typically using attributes or metadata) must be valid for every possible
 representation of the pointer.
 
+Non-integral pointer representation
+^^^
+
+Pointers are not represented as just an address, but may instead include
+additional metadata such as bounds information or a temporal identifier.
+Examples include AMDGPU buffer descriptors with a 128-bit fat pointer and a
+32-bit offset, or CHERI capabilities that contain bounds, permissions and a
+type field (as well as an out-of-band validity bit, see next section).
+In general, valid non-integral pointers cannot becreated from just an integer
+value: while ``inttoptr`` yields a deterministic bitwise pattern, the resulting
+value is not guaranteed to be a valid dereferenceable pointer.
+
+In most cases pointers with a non-integral representation behave exactly the
+same as an integral pointer, the only difference is that it is not possible to
+create a pointer just from an address.
+
+"Non-integral" pointers also impose restrictions on transformation passes, but
+in general these are less restrictive than for "unstable" pointers. The main
+difference compared to integral pointers is that ``inttoptr`` instructions
+should not be inserted by passes as they may not be able to create a vali

[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

2025-03-19 Thread Krzysztof Drewniak via llvm-branch-commits



@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
 
 .. _nointptrtype:
 
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
 
-Note: non-integral pointer types are a work in progress, and they should be
-considered experimental at this time.
+Note: non-integral/unstable pointer types are a work in progress, and they
+should be considered experimental at this time.
 
 LLVM IR optionally allows the frontend to denote pointers in certain address
-spaces as "non-integral" via the :ref:`datalayout string`.
-Non-integral pointer types represent pointers that have an *unspecified* 
bitwise
-representation; that is, the integral representation may be target dependent or
-unstable (not backed by a fixed integer).
+spaces as "non-integral" or "unstable" (or both "non-integral" and "unstable")
+via the :ref:`datalayout string`.
+
+The exact implications of these properties are target-specific, but the
+following IR semantics and restrictions to optimization passes apply:
+
+Unstable pointer representation
+^^^
+
+Pointers in this address space have an *unspecified* bitwise representation
+(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
+allowed to change in a target-specific way. For example, this could be a 
pointer
+type used with copying garbage collection where the garbage collector could
+update the pointer at any time in the collection sweep.
 
 ``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
 integral (i.e. normal) pointers in that they convert integers to and from
-corresponding pointer types, but there are additional implications to be
-aware of.  Because the bit-representation of a non-integral pointer may
-not be stable, two identical casts of the same operand may or may not
+corresponding pointer types, but there are additional implications to be aware
+of.
+
+For "unstable" pointer representations, the bit-representation of the pointer
+may not be stable, so two identical casts of the same operand may or may not
 return the same value.  Said differently, the conversion to or from the
-non-integral type depends on environmental state in an implementation
+"unstable" pointer type depends on environmental state in an implementation
 defined manner.
-
 If the frontend wishes to observe a *particular* value following a cast, the
 generated IR must fence with the underlying environment in an implementation
 defined manner. (In practice, this tends to require ``noinline`` routines for
 such operations.)
 
 From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
-non-integral types are analogous to ones on integral types with one
+"unstable" pointer types are analogous to ones on integral types with one
 key exception: the optimizer may not, in general, insert new dynamic
 occurrences of such casts.  If a new cast is inserted, the optimizer would
 need to either ensure that a) all possible values are valid, or b)
 appropriate fencing is inserted.  Since the appropriate fencing is
 implementation defined, the optimizer can't do the latter.  The former is
 challenging as many commonly expected properties, such as
-``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
+``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for "unstable" pointer types.
 Similar restrictions apply to intrinsics that might examine the pointer bits,
 such as :ref:`llvm.ptrmask`.
 
-The alignment information provided by the frontend for a non-integral pointer
+The alignment information provided by the frontend for an "unstable" pointer
 (typically using attributes or metadata) must be valid for every possible
 representation of the pointer.
 
+Non-integral pointer representation
+^^^
+
+Pointers are not represented as just an address, but may instead include
+additional metadata such as bounds information or a temporal identifier.
+Examples include AMDGPU buffer descriptors with a 128-bit fat pointer and a
+32-bit offset, or CHERI capabilities that contain bounds, permissions and a
+type field (as well as an out-of-band validity bit, see next section).
+In general, valid non-integral pointers cannot becreated from just an integer
+value: while ``inttoptr`` yields a deterministic bitwise pattern, the resulting
+value is not guaranteed to be a valid dereferenceable pointer.
+
+In most cases pointers with a non-integral representation behave exactly the
+same as an integral pointer, the only difference is that it is not possible to
+create a pointer just from an address.
+
+"Non-integral" pointers also impose restrictions on transformation passes, but
+in general these are less restrictive than for "unstable" pointers. The main
+difference compared to integral pointers is that ``inttoptr`` instructions
+should not be inserted by passes as they may not be able to create a vali

[llvm-branch-commits] [clang] [clang] NFC: Unify implementations of CheckMemberPointerConversion (PR #131966)

2025-03-19 Thread Erich Keane via llvm-branch-commits


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


https://github.com/llvm/llvm-project/pull/131966
___
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] [llvm] [llvm] Introduce callee_type operand bundle (PR #87573)

2025-03-19 Thread Nikita Popov via llvm-branch-commits


nikic wrote:

I still don't think that using operand bundles for this is appropriate. If you 
take a look at all the other operand bundles 
(https://llvm.org/docs/LangRef.html#operand-bundles) they consistently have 
some kind of impact on the semantics of the call. Also keep in mind that the 
default implication of an operand bundle is that it can read and write 
arbitrary memory. This is not going to be super relevant in this context 
because indirect calls already have unknown effects, but would be relevant if 
devirtualization happens and the operand bundle is still attached.

If you properly design the metadata, I expect that preservation through 
optimization will be quite robust. There just aren't that many optimizations 
that act on indirect calls. The main one is merging of multiple call-sites via 
hoist/sink, and metadata can handle that.

I'll also add that no matter what design you use, you still need to have some 
kind of graceful fallback for the case where the callee_type bundle/metadata is 
missing, e.g. because you're linking in an object from a frontend that doesn't 
support it.

cc @efriedma-quic for a second opinion on what to do here.

https://github.com/llvm/llvm-project/pull/87573
___
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] [clang-tools-extra] [clang] improve class type sugar preservation in pointers to members (PR #130537)

2025-03-19 Thread Erich Keane via llvm-branch-commits


erichkeane wrote:

> Done, in order to expedite review, I have split-off three patches from this:
> 
> * [[clang] ASTContext: flesh out implementation of getCommonNNS 
> #131964](https://github.com/llvm/llvm-project/pull/131964)
> 
> * [[clang] NFC: Clear some uses of MemberPointerType::getClass 
> #131965](https://github.com/llvm/llvm-project/pull/131965)
> 
> * [[clang] NFC: Unify implementations of CheckMemberPointerConversion 
> #131966](https://github.com/llvm/llvm-project/pull/131966)

Thanks!  Also, ooof, still 69 changed files.

https://github.com/llvm/llvm-project/pull/130537
___
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] [SDAG] Introduce inbounds flag for pointer arithmetic (PR #131862)

2025-03-19 Thread Fabian Ritter via llvm-branch-commits

ritter-x2a wrote:

> This seems semantically ambiguous.
> 
> In GlobalISel, you have G_PTR_ADD, and inbounds on that has an obvious 
> meaning; G_PTR_ADD has basically the same semantics as getelementptr. But in 
> SelectionDAG, we don't have that; we just have a plain ISD::ADD. How do you 
> tell which operand is the pointer? The obvious heuristic is outright wrong: 
> you can't assume a value is being used as a pointer just because its value is 
> equal to the address of some variable.

I see your point. We could define the semantics of an inbounds ISD::ADD to be 
"The result is an address into an allocated object and (exactly) one of the 
operands is an address into the same allocated object."
I think this might be strong enough for the concrete goal that I have in mind 
(PR #131863), but I agree that it would be better to have a flag that is easier 
to make use of.

What do you think about a "ConstInBoundsOffset" flag instead (suggestions for 
better names would be much appreciated), meaning "One operand is a constant 
offset and the other is an address pointing into the same allocated object as 
the result"?
While a lot narrower in scope, it would be easier to make use of that.

https://github.com/llvm/llvm-project/pull/131862
___
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] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

2025-03-19 Thread Krzysztof Drewniak via llvm-branch-commits



@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
 
 .. _nointptrtype:
 
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
 
-Note: non-integral pointer types are a work in progress, and they should be
-considered experimental at this time.
+Note: non-integral/unstable pointer types are a work in progress, and they
+should be considered experimental at this time.
 
 LLVM IR optionally allows the frontend to denote pointers in certain address
-spaces as "non-integral" via the :ref:`datalayout string`.
-Non-integral pointer types represent pointers that have an *unspecified* 
bitwise
-representation; that is, the integral representation may be target dependent or
-unstable (not backed by a fixed integer).
+spaces as "non-integral" or "unstable" (or both "non-integral" and "unstable")
+via the :ref:`datalayout string`.
+
+The exact implications of these properties are target-specific, but the
+following IR semantics and restrictions to optimization passes apply:
+
+Unstable pointer representation
+^^^
+
+Pointers in this address space have an *unspecified* bitwise representation
+(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
+allowed to change in a target-specific way. For example, this could be a 
pointer
+type used with copying garbage collection where the garbage collector could
+update the pointer at any time in the collection sweep.
 
 ``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
 integral (i.e. normal) pointers in that they convert integers to and from
-corresponding pointer types, but there are additional implications to be
-aware of.  Because the bit-representation of a non-integral pointer may
-not be stable, two identical casts of the same operand may or may not
+corresponding pointer types, but there are additional implications to be aware
+of.
+
+For "unstable" pointer representations, the bit-representation of the pointer
+may not be stable, so two identical casts of the same operand may or may not
 return the same value.  Said differently, the conversion to or from the
-non-integral type depends on environmental state in an implementation
+"unstable" pointer type depends on environmental state in an implementation
 defined manner.
-
 If the frontend wishes to observe a *particular* value following a cast, the
 generated IR must fence with the underlying environment in an implementation
 defined manner. (In practice, this tends to require ``noinline`` routines for
 such operations.)
 
 From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
-non-integral types are analogous to ones on integral types with one
+"unstable" pointer types are analogous to ones on integral types with one
 key exception: the optimizer may not, in general, insert new dynamic
 occurrences of such casts.  If a new cast is inserted, the optimizer would
 need to either ensure that a) all possible values are valid, or b)
 appropriate fencing is inserted.  Since the appropriate fencing is
 implementation defined, the optimizer can't do the latter.  The former is
 challenging as many commonly expected properties, such as
-``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
+``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for "unstable" pointer types.
 Similar restrictions apply to intrinsics that might examine the pointer bits,
 such as :ref:`llvm.ptrmask`.
 
-The alignment information provided by the frontend for a non-integral pointer
+The alignment information provided by the frontend for an "unstable" pointer
 (typically using attributes or metadata) must be valid for every possible
 representation of the pointer.
 
+Non-integral pointer representation
+^^^
+
+Pointers are not represented as just an address, but may instead include
+additional metadata such as bounds information or a temporal identifier.
+Examples include AMDGPU buffer descriptors with a 128-bit fat pointer and a
+32-bit offset, or CHERI capabilities that contain bounds, permissions and a
+type field (as well as an out-of-band validity bit, see next section).
+In general, valid non-integral pointers cannot becreated from just an integer
+value: while ``inttoptr`` yields a deterministic bitwise pattern, the resulting
+value is not guaranteed to be a valid dereferenceable pointer.
+
+In most cases pointers with a non-integral representation behave exactly the
+same as an integral pointer, the only difference is that it is not possible to
+create a pointer just from an address.
+
+"Non-integral" pointers also impose restrictions on transformation passes, but
+in general these are less restrictive than for "unstable" pointers. The main
+difference compared to integral pointers is that ``inttoptr`` instructions
+should not be inserted by passes as they may not be able to create a vali

[llvm-branch-commits] [llvm] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

2025-03-19 Thread Krzysztof Drewniak via llvm-branch-commits


https://github.com/krzysz00 commented:

I like the external state thing and think this is a good clarification / 
breakdown overall, just one comment

https://github.com/llvm/llvm-project/pull/105735
___
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] [DataLayout][LangRef] Split non-integral and unstable pointer properties (PR #105735)

2025-03-19 Thread Krzysztof Drewniak via llvm-branch-commits


https://github.com/krzysz00 edited 
https://github.com/llvm/llvm-project/pull/105735
___
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] [SDAG] Introduce inbounds flag for pointer arithmetic (PR #131862)

2025-03-19 Thread David Green via llvm-branch-commits


davemgreen wrote:

There is a ISD::PTRADD in https://github.com/llvm/llvm-project/pull/105669, 
which still has some open questions about whether the AMDGPU use of the 
tablegen `ptradd` can be redefined.

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

49 matches

Mail list logo