@@ -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
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
@@ -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
jrtc27 wrote:
> I had to do something very similar for CHERI downstream: We have to ensure
> that all globals are precisely representable (which may require rounding up
> the size+alignment) so you don't end up creating bounds that include adjacent
> ones. The original patch from 2019 is here:
@@ -78,6 +78,19 @@ def GENERIC_RV64 : RISCVProcessorModel<"generic-rv64",
// to change to the appropriate rv32/rv64 version.
def GENERIC : RISCVTuneProcessorModel<"generic", NoSchedModel>,
GenericTuneInfo;
+def MIPS_P8700 : RISCVProcessorModel<"mips-p8700",
+
@@ -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,158 @@
+//===--- RISCVRemoveBackToBackBranches.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,158 @@
+//===--- RISCVRemoveBackToBackBranches.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
jrtc27 wrote:
Extensions belong in their own PRs, ditto CPU/scheduler, driver and any
additional passes. Each PR is one commit and this is not one commit's worth of
changes.
https://github.com/llvm/llvm-project/pull/117865
___
cfe-commits mailing lis
@@ -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
@@ -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
@@ -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)
---
@@ -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
@@ -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
jrtc27 wrote:
> Considering the define is guarded behind `if
> (ISAInfo->hasExtension("zve32x"))`, this doesn't seem to implement:
> [riscv-non-isa/rvv-intrinsic-doc#382](https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/382)
Presumably that (rather terse) sentence in the specification i
jrtc27 wrote:
I disagree that this is a thing which should exist. It's solving the problem in
the wrong place.
https://github.com/llvm/llvm-project/pull/115981
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/113732
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -280,14 +280,18 @@ static void initRISCVFeature(struct riscv_hwprobe
Hwprobes[]) {
static int FeaturesBitCached = 0;
-void __init_riscv_feature_bits() CONSTRUCTOR_ATTRIBUTE;
+void __init_riscv_feature_bits(void *) CONSTRUCTOR_ATTRIBUTE;
// A constructor function that s
@@ -280,14 +280,18 @@ static void initRISCVFeature(struct riscv_hwprobe
Hwprobes[]) {
static int FeaturesBitCached = 0;
-void __init_riscv_feature_bits() CONSTRUCTOR_ATTRIBUTE;
+void __init_riscv_feature_bits(void *) CONSTRUCTOR_ATTRIBUTE;
// A constructor function that s
jrtc27 wrote:
> > "[LLVM] Trim intrinsics" is not a helpful commit message. What exactly are
> > you trying to achieve and why? Is there an RFC for this given it seems to
> > be having significant consequences across the tree?
>
> Yes, please see here:
> https://discourse.llvm.org/t/rfc-compr
jrtc27 wrote:
"[LLVM] Trim intrinsics" is not a helpful commit message. What exactly are you
trying to achieve and why? Is there an RFC for this given it seems to be having
significant consequences across the tree?
https://github.com/llvm/llvm-project/pull/112791
__
@@ -1,3 +1,4 @@
+// REQUIRES: directx-registered-target
jrtc27 wrote:
This seems wrong. Emitting LLVM from the Clang frontend should not require
anything about the set of targets enabled in LLVM itself.
https://github.com/llvm/llvm-project/pull/112791
_
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/112791
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jrtc27 closed
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
@awilfox Could you please verify if this fixes the bug for you?
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/112927
>From 4f37ed5ff6c18c8cf0de244bb064d5f4f60065a4 Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Fri, 18 Oct 2024 16:50:22 +0100
Subject: [PATCH 1/2] [clang] Make LazyOffsetPtr more portable
LazyOffsetPtr curr
jrtc27 wrote:
> One style nit, otherwise looks good, thanks!
I'm not sure "good" is quite the right word given the horrors this interface is
hiding, but thanks for the review!
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing l
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/112927
LazyOffsetPtr currently relies on uint64_t being able to store a pointer
and, unless sizeof(uint64_t) == sizeof(void *), little endianness, since
getAddressOfPointer reinterprets the memory as a pointer. This also
jrtc27 wrote:
> > But yes, the short answer is that the code as written should work on
> > Morello and CHERI-RISC-V.
>
> Great, thanks.
>
> > > > The std::launder may be unnecessary
> > >
> > >
> > > Formally I think it's correct and necessary for the pointer and integer
> > > case because
jrtc27 wrote:
> > How about:
> > [...]
>
> Yeah, I think that fixes it. For me that looks a lot less simple than using a
> union, but it is nice to have only a single implementation. I'd be fine with
> going in that direction.
>
> For CHERI, can we assume that the least-significant byte of th
@@ -321,50 +322,87 @@ class ExternalASTSource : public
RefCountedBase {
/// external AST source itself.
template
struct LazyOffsetPtr {
- /// Either a pointer to an AST node or the offset within the
- /// external AST source where the AST node can be found.
- ///
- /// If
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
> > > > #112806 should address this without narrowing the field to 32 bits.
> > >
> > >
> > > As does [#111995
> > > (comment)](https://github.com/llvm/llvm-project/pull/111995#discussion_r1805329590),
> > > with less code and more generality
> >
> >
> > I prefer this solution
@@ -321,50 +322,87 @@ class ExternalASTSource : public
RefCountedBase {
/// external AST source itself.
template
struct LazyOffsetPtr {
- /// Either a pointer to an AST node or the offset within the
- /// external AST source where the AST node can be found.
- ///
- /// If
jrtc27 wrote:
> #112806 should address this without narrowing the field to 32 bits.
As does
https://github.com/llvm/llvm-project/pull/111995#discussion_r1805329590, with
less code and more generality
https://github.com/llvm/llvm-project/pull/111995
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/110098
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2970,22 +2974,28 @@ void CodeGenFunction::EmitRISCVMultiVersionResolver(
// (__riscv_feature_bits.features[i] & REQUIRED_BITMASK) ==
// REQUIRED_BITMASK
//
+// First, check __riscv_feature_bits.length <=
+// llvm::RISCVISAInfo::FeatureBitSize. This ensur
@@ -0,0 +1,47 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=riscv64-unknown-elf -verify-machineinstrs < %s \
+; RUN: | FileCheck %s
+
+define void @foo(i64 %t) sspstrong {
jrtc27 w
@@ -0,0 +1,47 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=riscv64-unknown-elf -verify-machineinstrs < %s \
+; RUN: | FileCheck %s
+
+define void @foo(i64 %t) sspstrong {
jrtc27 w
@@ -0,0 +1,47 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=riscv64-unknown-elf -verify-machineinstrs < %s \
jrtc27 wrote:
This was previously linux-gnu not elf. If it works fine with
@@ -23,3 +26,9 @@ void bar(int x) {
// AARCH64: [[ATTR1]] = !{i32 1, !"stack-protector-guard", !"sysreg"}
// AARCH64: [[ATTR2]] = !{i32 1, !"stack-protector-guard-reg", !"sp_el0"}
// AARCH64: [[ATTR3]] = !{i32 1, !"stack-protector-guard-offset", i32 1024}
+
+// RISCV: !llvm.mod
jrtc27 wrote:
Same comments as -global
https://github.com/llvm/llvm-project/pull/108942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -verify-machineinstrs < %s | \
+; RUN: FileCheck %s
+
+target triple = "riscv64-unknown-linux-gnu"
+
+define dso_local void @foo(i64 %t) local_unnamed
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -verify-machineinstrs < %s | \
+; RUN: FileCheck %s
+
+target triple = "riscv64-unknown-linux-gnu"
+
+define dso_local void @foo(i64 %t) local_unnamed
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -verify-machineinstrs < %s | \
+; RUN: FileCheck %s
jrtc27 wrote:
The line above isn't (currently) long enough to warrant wrapping,
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -verify-machineinstrs < %s | \
+; RUN: FileCheck %s
+
+target triple = "riscv64-unknown-linux-gnu"
+
+define dso_local void @foo(i64 %t) local_unnamed
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -verify-machineinstrs < %s | \
+; RUN: FileCheck %s
+
+target triple = "riscv64-unknown-linux-gnu"
jrtc27 wrote:
Convention is to pu
@@ -245,6 +246,7 @@ class DataLayout {
unsigned getDefaultGlobalsAddressSpace() const {
return DefaultGlobalsAddrSpace;
}
+ unsigned getFlatAddressSpace() const { return FlatAddressSpace; }
jrtc27 wrote:
> The absence of this specification indicates t
@@ -0,0 +1,41 @@
+//==- BuiltinsRISCVXCV.td - RISC-V CORE-V Builtin database*- 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: Apa
@@ -44,7 +44,7 @@ ArrayRef RISCVTargetInfo::getGCCRegNames()
const {
"v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31",
// CSRs
- "fflags", "frm", "vtype", "vl", "vxsat", "vxrm"
+ "fflags", "frm", "vtype", "vl", "vxsat", "vxrm", "sf_vcix_state"
https://github.com/jrtc27 closed
https://github.com/llvm/llvm-project/pull/105726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
NB: I would appreciate a review from someone outside the CHERI project
https://github.com/llvm/llvm-project/pull/105726
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jrtc27 updated
https://github.com/llvm/llvm-project/pull/105726
>From cfce8b0d99a088a6a2fb12661a7158786f630802 Mon Sep 17 00:00:00 2001
From: Jessica Clarke
Date: Thu, 22 Aug 2024 21:20:23 +0100
Subject: [PATCH] [CodeGen] Create IFUNCs in the program address space, not
hard-
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/105726
Commit 0d527e56a5ee ("GlobalIFunc: Make ifunc respect function address
spaces") added support for this within LLVM, but Clang does not properly
honour the target's address spaces when creating IFUNCs, crashing wit
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s
+//
+// -expected-no-diagnostics
jrtc27 wrote:
?
https://github.com/llvm/llvm-project/pull/96301
___
cfe-commits mailing list
cfe-commits@lists.l
jrtc27 wrote:
Some relevant context for what CPUs we permit merging into LLVM:
https://github.com/llvm/llvm-project/pull/102452#issuecomment-2275962014
How does this apply to NutShell?
https://github.com/llvm/llvm-project/pull/102899
___
cfe-commits
https://github.com/jrtc27 closed
https://github.com/llvm/llvm-project/pull/101765
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jrtc27 wrote:
For the avoidance of doubt, I would appreciate a review from a core Clang
developer, given Alex also comes from a CHERI LLVM background.
https://github.com/llvm/llvm-project/pull/101765
___
cfe-commits mailing list
cfe-commits@lists.llvm
https://github.com/jrtc27 created
https://github.com/llvm/llvm-project/pull/101765
ASTContext::getIntWidth returns 1 if isBooleanType(), and falls back on
getTypeSize in the default case, which itself just returns the Width
from getTypeInfo's returned struct, so can be used in all cases here,
no
https://github.com/jrtc27 edited
https://github.com/llvm/llvm-project/pull/100684
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -59,16 +59,26 @@ let TargetPrefix = "riscv" in {
[IntrNoMem, IntrWillReturn, IntrSpeculatable,
ImmArg>, ImmArg>]>;
+ def int_riscv_cv_alu_slet : ScalarCoreVAluGprGprIntrinsic;
jrtc27 wrote:
*Especia
@@ -59,16 +59,26 @@ let TargetPrefix = "riscv" in {
[IntrNoMem, IntrWillReturn, IntrSpeculatable,
ImmArg>, ImmArg>]>;
+ def int_riscv_cv_alu_slet : ScalarCoreVAluGprGprIntrinsic;
jrtc27 wrote:
Is it to
@@ -1240,11 +1240,22 @@ void IRLinker::linkNamedMDNodes() {
if (IsPerformingImport && NMD.getName() == "llvm.stats")
continue;
+// Default subtarget info is only intended to be used before LTO and
+// shouldn't be present after merging because the default sub
jrtc27 wrote:
AFAIK LLD doesn't support Zicfilp yet, which I feel is a prerequisite to
marking it as non-experimental
https://github.com/llvm/llvm-project/pull/98891
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
@@ -1764,6 +1764,13 @@ class TargetInfo : public TransferrableTargetInfo,
return 0;
}
+ /// \returns Target specific flat ptr address space; a flat ptr is a ptr that
+ /// can be casted to / from all other target address spaces. If the target
+ /// exposes no such add
jrtc27 wrote:
> If we are talking about the necessariness of adding these intrinsics, please
> refer to the ARM implementations in DPDK
> (https://github.com/DPDK/dpdk/blob/76cef1af8bdaeaf67a5c4ca5df3f221df994dc46/lib/eal/arm/include/rte_pause_64.h).
>
> We want to use Zawrs&Zalrsc instruction
jrtc27 wrote:
> > lr/sc builtins are extremely fragile: there's no reasonable way for the
> > compiler to guarantee that the sc is placed in such a way that it will
> > eventually succeed.
>
> I think the user should have enough knowledges about lr/sc to make the logic
> reasonable.
It's not
jrtc27 wrote:
And I still strongly urge renaming what this is, given it is _not_ the type for
an unqualified C `void *`, as one would normally expect given it's in Clang.
https://github.com/llvm/llvm-project/pull/94388
___
cfe-commits mailing list
cfe
jrtc27 wrote:
There are still quite a few references to UnqualPtrTy that you're not changing
yet are now wrong, no?
https://github.com/llvm/llvm-project/pull/94388
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
jrtc27 wrote:
I think the point is there are two things going on here that people think of as
unqualified:
1. "Give me a pointer that's whatever `void *` is"
2. "Give me a pointer in some address space just so I can put a global in some
metadata"
The vast majority of the time we're talking abou
jrtc27 wrote:
I don't think that assumption is currently true. I think it's also worth
clarifying what this thing is, and possibly renaming it, because "unqualified"
has C language level meaning that would contradict what it is here.
https://github.com/llvm/llvm-project/pull/94388
https://github.com/jrtc27 approved this pull request.
Didn't reproduce it myself, just worked out the problem from the build log. If
this test still works locally for you then this should fix it.
https://github.com/llvm/llvm-project/pull/94276
___
cfe
jrtc27 wrote:
Looks like the buildbots' -DDEFAULT_SYSROOT strikes again (boo...). I think
adding --sysroot="" is a common way to handle this for tests.
https://github.com/llvm/llvm-project/pull/94055
___
cfe-commits mailing list
cfe-commits@lists.llvm
jrtc27 wrote:
The third argument here is like for llvm.used, it's a way to associate the
entry with a global or function. If the corresponding global or function is
omitted from the output then the entry will be removed. It isn't used for
anything at run time. So I think there should be a cons
@@ -35,6 +35,8 @@ class RISCVTargetStreamer : public MCTargetStreamer {
RISCVABI::ABI TargetABI = RISCVABI::ABI_Unknown;
bool HasRVC = false;
bool HasTSO = false;
+ bool HasZICFILP = false;
jrtc27 wrote:
Make the fields and methods all Zifoo
https://gi
@@ -118,6 +147,19 @@ void RISCVTargetELFStreamer::finish() {
}
MCA.setELFHeaderEFlags(EFlags);
+
+ unsigned GNUNoteFlags = 0;
+
+ // check ZICFILP or ZICFISS with features
jrtc27 wrote:
Not sure this adds anything, but if it's staying please properly st
@@ -118,6 +147,19 @@ void RISCVTargetELFStreamer::finish() {
}
MCA.setELFHeaderEFlags(EFlags);
+
+ unsigned GNUNoteFlags = 0;
+
+ // check ZICFILP or ZICFISS with features
+ // TODO should we check with codegen enable ex. -mllvm
jrtc27 wrote:
This seem
@@ -5283,14 +5291,21 @@ static std::string getGNUProperty(uint32_t Type,
uint32_t DataSize,
OS << "";
return OS.str();
}
+
if (Type == GNU_PROPERTY_AARCH64_FEATURE_1_AND) {
- DumpBit(GNU_PROPERTY_AARCH64_FEATURE_1_BTI, "BTI");
- DumpBit(GNU_PROPE
@@ -85,6 +85,35 @@ void RISCVTargetELFStreamer::finishAttributeSection() {
ELF::SHT_RISCV_ATTRIBUTES, AttributeSection);
}
+void RISCVTargetELFStreamer::emitNoteSection(unsigned Flags) {
jrtc27 wrote:
I know this is what AArch64 call
1 - 100 of 216 matches
Mail list logo
