@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -57,6 +57,10 @@ static const int16_t cSledLength = 64;
static const int16_t cSledLength = 8;
#elif defined(__hexagon__)
static const int16_t cSledLength = 20;
+#elif SANITIZER_RISCV64
+static const int16_t cSledLength = 76;
+#elif defined(__riscv) && (__riscv_xlen == 32)
---
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/117368
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,296 @@
+//===-- xray_riscv.cpp *- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far");
Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth()));
- Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify -std=c23 -ffreestanding %s
+
+/* WG14 N2412: Clang 14
+ * Two's complement sign representation
+ */
+// expected-no-diagnostics
+
+#include
+
+// GH117348 -- BOOL_WIDTH was accidentally expanding to the number of bits in
+// the object
@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far");
Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth()));
- Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool
jrtc27 wrote:
> Side note: my motivation in removing StringLiteral is that it is a bit of a
> footgun. While the original https://reviews.llvm.org/D27686 clearly states
> that it's intended for arrays of string literals, where it would not be
> possible anyway to store each literal as a true l
@@ -62,6 +62,15 @@ static cl::opt RISCVMinimumJumpTableEntries(
"riscv-min-jump-table-entries", cl::Hidden,
cl::desc("Set minimum number of entries to use a jump table on RISCV"));
+static cl::opt
+UseLoadStorePairsOpt("riscv-load-store-pairs",
jrt
@@ -0,0 +1,82 @@
+//===-- RISCVInstrInfoXMips.td -*- tablegen
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
As far as I know GPUs don't do TLS...
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/132489
Thraed-local globals live, by default, in the default globals address
space, which may not be 0, so we need to overload @llvm.thread.pointer
to support other address spaces, and use the default globals address
spa
jrtc27 wrote:
Is there a reason why these aren't lowercase like the rest?
https://github.com/llvm/llvm-project/pull/132481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
Although C++ might have good alternatives, that's not so helpful for C headers
being included from C++ that might end up using this (e.g. some static inline
function in a system header).
https://github.com/llvm/llvm-project/pull/133125
@@ -202,6 +202,7 @@
// CHECK-NEXT: xqcilo 0.2 'Xqcilo' (Qualcomm uC Large
Offset Load Store Extension)
// CHECK-NEXT: xqcilsm 0.2 'Xqcilsm' (Qualcomm uC Load
Store Multiple Extension)
// CHECK-NEXT: xqcisls 0.2
jrtc27 wrote:
Is this the kind of thing we have agreed to take in LLVM? If it's "simulation
hint" instructions, does that not by definition mean that it's not an extension
present in real hardware?
https://github.com/llvm/llvm-project/pull/128833
___
jrtc27 wrote:
Ping
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
> I think you also need to fix the backends so if they see thread_pointer
> intrinsic with the wrong address-space, they don't crash.
I don't believe they do crash? At least, I can't construct IR using any
addrspace (even some of the special X86 ones) that makes amd64/aarch64/ris
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/132489
>From 778502b697d7fe547e827f7d7394a7013a1c9ffb Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Fri, 21 Mar 2025 23:15:23 +
Subject: [PATCH 1/3] [clang][IR] Overload @llvm.thread.pointer to support
non-AS
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/132489
>From 778502b697d7fe547e827f7d7394a7013a1c9ffb Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Fri, 21 Mar 2025 23:15:23 +
Subject: [PATCH 1/2] [clang][IR] Overload @llvm.thread.pointer to support
non-AS
jrtc27 wrote:
> I'm mostly concerned about the case where the lowered node has the wrong
> type. For example, AArch64TargetLowering::LowerINTRINSIC_WO_CHAIN always
> creates a value with the pointer width of addrspace 0, but address spaces
> exist which don't have the native pointer width (arm
https://github.com/jrtc27 closed
https://github.com/llvm/llvm-project/pull/132489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
201 - 231 of 231 matches
Mail list logo