[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -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://github.com/llvm/llvm-project/pull/77414
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -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 style it (e.g. 
start with a capital letter)

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

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -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 seems like it should be resolved before merging?

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

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -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_PROPERTY_AARCH64_FEATURE_1_PAC, "PAC");
-  DumpBit(GNU_PROPERTY_AARCH64_FEATURE_1_GCS, "GCS");
+  if (Target == ELF::EM_RISCV) {
+DumpBit(GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE, "ZICFILP");
+DumpBit(GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS, "ZICFISS");

jrtc27 wrote:

```suggestion
DumpBit(GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_SIMPLE, "Zicfilp");
DumpBit(GNU_PROPERTY_RISCV_FEATURE_1_CFI_SS, "Zicfiss");
```
I assume the others are all-caps because that's what their canonical names are, 
not because that's desirable

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

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -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 calls it, but it's a very vague name that could 
cover any number of note sections. Can we do better and make ours specific to 
what it's actually doing, i.e. something about it being a GNU properties note?

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

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

[Jessica Clarke via cfe-commits]

@@ -5272,8 +5272,16 @@ static std::string getGNUProperty(uint32_t Type, 
uint32_t DataSize,
 return OS.str();
   case GNU_PROPERTY_AARCH64_FEATURE_1_AND:
   case GNU_PROPERTY_X86_FEATURE_1_AND:
-OS << ((Type == GNU_PROPERTY_AARCH64_FEATURE_1_AND) ? "aarch64 feature: "
-: "x86 feature: ");
+

jrtc27 wrote:

```suggestion
```

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

[clang] [llvm] [RISCV] Allow extra underscores in parseNormalizedArchString and parseArchString. (PR #91532)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

This one seems lazy, avoiding trailing or duplicate underscores is easy.

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

[clang] [llvm] [RISCV] Teach .option arch to support experimental extensions. (PR #89727)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,7 @@
+// RUN: %clang --target=riscv64 -menable-experimental-extensions -c -o 
/dev/null %s

jrtc27 wrote:

Why are these clang tests? This is entirely testing llvm/ code. Never mind the 
weirdness of putting them in Driver/, nor the fact that they’re missing a 
REQUIRES: riscv-registered-target given they use the backend, they don’t belong 
in clang/ at all surely?

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

[clang] [llvm] [RISCV] Teach .option arch to support experimental extensions. (PR #89727)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,7 @@
+// RUN: %clang --target=riscv64 -menable-experimental-extensions -c -o 
/dev/null %s
+// RUN: ! %clang --target=riscv64 -c -o /dev/null %s 2>&1 | FileCheck 
-check-prefixes=CHECK-ERR %s

jrtc27 wrote:

Use not rather than !

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

[clang] [llvm] [mlir] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

@@ -1,14 +1,17 @@
 // RUN: %clang_cc1 %s -triple=amdgcn-amd-amdhsa -std=c++11 -emit-llvm -o %t.ll 
-O1 -disable-llvm-passes -fms-extensions -fstrict-vtable-pointers
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -emit-llvm -o %t.ms.ll -O1 
-disable-llvm-passes -fms-extensions -fstrict-vtable-pointers
+// RUN: %clang_cc1 %s -triple=spirv64-unknown-unknown -fsycl-is-device 
-std=c++11 -emit-llvm -o %t.ll -O1 -disable-llvm-passes -fms-extensions 
-fstrict-vtable-pointers
 // FIXME: Assume load should not require -fstrict-vtable-pointers
 
 // RUN: FileCheck --check-prefix=CHECK1 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK2 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK3 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK4 --input-file=%t.ll %s
-// RUN: FileCheck --check-prefix=CHECK5 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK-MS --input-file=%t.ms.ll %s
 // RUN: FileCheck --check-prefix=CHECK6 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK7 --input-file=%t.ll %s
 // RUN: FileCheck --check-prefix=CHECK8 --input-file=%t.ll %s
+// RUN: FileCheck --check-prefix=CHECK9 --input-file=%t.ll %s

jrtc27 wrote:

Why renumber everything? Just add yours to the end?

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

[clang] [llvm] [mlir] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

@@ -23,8 +26,8 @@ struct B : A {
 void g(A *a) { a->foo(); }
 
 // CHECK1-LABEL: define{{.*}} void @_ZN5test14fooAEv()
-// CHECK1: call void @_ZN5test11AC1Ev(ptr
-// CHECK1: %[[VTABLE:.*]] = load ptr addrspace(1), ptr %{{.*}}
+// CHECK1: call{{.*}} void @_ZN5test11AC1Ev(ptr {{((addrspace(4)){0,1})}}

jrtc27 wrote:

I don’t love how this isn’t checking the address space is correct for each, 
only that it’s one of the two valid ones

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

[clang] [compiler-rt] [libc] [libclc] [libcxxabi] [lld] [lldb] [llvm] [mlir] Add clarifying parenthesis around non-trivial conditions in ternary expressions. (PR #90391)

[Jessica Clarke via cfe-commits]

@@ -3802,7 +3802,7 @@ bool X86AsmParser::validateInstruction(MCInst , 
const OperandVector ) {
 //VFMULCPHZrr   Dest, Src1, Src2
 //VFMULCPHZrrk  Dest, Dest, Mask, Src1, Src2
 //VFMULCPHZrrkz Dest, Mask, Src1, Src2
-for (unsigned i = TSFlags & X86II::EVEX_K ? 2 : 1;

jrtc27 wrote:

The second level seems like a bug, it's not consistent with how `type 
identifier = expr ? expr : expr;` is handled in a block.

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

[clang] [llvm] [RISCV][FMV] Support target_clones (PR #85786)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,14 @@
+// RUN: not %clang_cc1 -triple riscv64-linux-gnu -target-feature +i -S 
-emit-llvm -o - %s 2>&1 | FileCheck %s --check-prefix=CHECK-UNSUPPORT-EXT
+// RUN: not %clang_cc1 -triple riscv64 -target-feature +i -S -emit-llvm -o - 
%s 2>&1 | FileCheck %s --check-prefix=CHECK-UNSUPPORT-OS
+
+// CHECK-UNSUPPORT-EXT: error: Unsupport 'zicsr' for _riscv_hwprobe
+__attribute__((target_clones("default", "arch=+zicsr"))) int foo1(void) {
+  return 1;
+}
+
+// CHECK-UNSUPPORT-OS: error: Only Linux support _riscv_hwprobe

jrtc27 wrote:

Yes, that seems fine

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

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> > I'm not quite sure how to parse this comment, could you explain what you 
> > have in mind here? The problem is precisely that the FE assumes 0 is fine / 
> > picks it by default, which ends up into dangerzones when e.g. a target 
> > happened to use 0 to point to private (stack). I feel as if I'm missing the 
> > core of your comment though, so apologies in advance.
> 
> I'm just saying that I don't think it makes any sense to add a concept of a 
> default AS to LLVM. The "default" AS is a frontend concept, not a middle-end 
> / back-end concept. LLVM would only need a default AS if it were inventing a 
> memory allocation/operation from whole cloth, which is generally not 
> something LLVM should ever be doing; the only legitimate counter-example I 
> can think of would be something like materializing a constant into constant 
> global memory, in which case LLVM needs to assign the new constant an AS.

Libcall emission needs to know what AS to use for pointer arguments to things 
like __sync/__atomic implementations and various string-y mem*/str* functions. 
That's the main one that comes to mind from our experience in CHERI LLVM, and 
current LLVM just assumes that's AS0.

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

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> Why can't we just declare that the "generic" address-space must always be 0? 
> The specific numbers we use for address-spaces are completely arbitrary 
> anyway.

https://github.com/CTSRD-CHERI/llvm-project/issues/621 is what I wrote up for 
CHERI LLVM, but is a bit terse if you don't know about CHERI details. In 
essence, for us downstream in CHERI LLVM, we have two ABIs: hybrid and purecap. 
Hybrid is your standard pointers-are-integers ABI, with the ability to annotate 
select pointers as instead being capabilities. AS0 is used for integer 
pointers, as the default thing and to follow upstream, and AS200 is used for 
capability pointers as the new special thing. When it comes to purecap, *all* 
pointers are to be capabilities. We could change AS0 to be a capability in that 
scenario, but now the backend becomes a lot more complicated, because what 
address space means what is changing based on the ABI. So instead we leave AS0 
as meaning integer pointers (currently no syntax for them in CHERI C as they're 
not that useful, but they work fine in IR) and AS200 as meaning capability 
pointers, but that means AS0 can't be used for `void *` any more, which gets 
annoying with things like libcall handling code, where we have various hacks.

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

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> querying a modules default AS from the target, rather than assuming it's 0

I do think this should likely be part of the DataLayout. We have defaults for 
globals, alloca and functions, but no generic "give me the address space for 
`void *`"-like thing in LLVM itself.

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

[clang] [Clang][CodeGen] Start migrating away from assuming the Default AS is 0 (PR #88182)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> querying a modules global AS from the target, rather than from the data 
> layout (some DL's are incomplete, e.g. SPIRV's)

That is a bug in those DataLayouts

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

[clang] [llvm] [RISCV][FMV] Support target_clones (PR #85786)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/85786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV][FMV] Support target_clones (PR #85786)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,14 @@
+// RUN: not %clang_cc1 -triple riscv64-linux-gnu -target-feature +i -S 
-emit-llvm -o - %s 2>&1 | FileCheck %s --check-prefix=CHECK-UNSUPPORT-EXT
+// RUN: not %clang_cc1 -triple riscv64 -target-feature +i -S -emit-llvm -o - 
%s 2>&1 | FileCheck %s --check-prefix=CHECK-UNSUPPORT-OS
+
+// CHECK-UNSUPPORT-EXT: error: Unsupport 'zicsr' for _riscv_hwprobe
+__attribute__((target_clones("default", "arch=+zicsr"))) int foo1(void) {
+  return 1;
+}
+
+// CHECK-UNSUPPORT-OS: error: Only Linux support _riscv_hwprobe

jrtc27 wrote:

That's not the right error message still. " is only 
supported on Linux" isn't the point, the point is that the current 
implementation only supports Linux because it is written to use that specific 
system call. Other OSes can and likely will provide alternative interfaces that 
could equally be used.

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -1318,16 +1318,16 @@ define void @instructions.va_arg(i8* %v, ...) {
   %ap2 = bitcast i8** %ap to i8*
 
   call void @llvm.va_start(i8* %ap2)
-  ; CHECK: call void @llvm.va_start(ptr %ap2)
+  ; CHECK: call void @llvm.va_start.p0(ptr %ap2)
 
   va_arg i8* %ap2, i32
   ; CHECK: va_arg ptr %ap2, i32
-
+s

jrtc27 wrote:

Typo

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

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

LGTM once typo is fixed

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/85460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

This probably also needs to tweak LangRef

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Doesn’t AutoUpgrade automatically infer overloads? You can see a bunch of tests 
in this patch where the output references the overloaded intrinsics but the 
input is unchanged.

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,22 @@
+// REQUIRES: spirv-registered-target
+// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm 
-o - %s | FileCheck %s
+struct x {

jrtc27 wrote:

Newline before

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -1713,7 +1716,7 @@ def int_coro_subfn_addr : DefaultAttrsIntrinsic<
 
 ///===-- Other Intrinsics 
--===//
 //
-// TODO: We should introduce a new memory kind fo traps (and other side 
effects 
+// TODO: We should introduce a new memory kind fo traps (and other side effects

jrtc27 wrote:

Don't touch unrelated whitespace

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,22 @@
+// REQUIRES: spirv-registered-target
+// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm 
-o - %s | FileCheck %s
+struct x {
+  double b;
+  long a;
+};
+
+void testva(int n, ...) {
+  __builtin_va_list ap;
+  __builtin_va_start(ap, n);
+  struct x t = __builtin_va_arg(ap, struct x);
+  __builtin_va_list ap2;
+  __builtin_va_copy(ap2, ap);
+  int v = __builtin_va_arg(ap2, int);
+  __builtin_va_end(ap2);
+  __builtin_va_end(ap);
+}
+
+// CHECK:  call void @llvm.va_start.p4(ptr addrspace(4) %ap{{.*}})
+// CHECK:  call void @llvm.va_copy.p4.p4(ptr addrspace(4) %ap2{{.*}}, ptr 
addrspace(4) {{.*}})
+// CHECK:  call void @llvm.va_end.p4(ptr addrspace(4) %ap2{{.*}})
+// CHECK-NEXT:  call void @llvm.va_end.p4(ptr addrspace(4) %ap{{.*}})

jrtc27 wrote:

Needs a newline

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,22 @@
+// REQUIRES: spirv-registered-target
+// RUN: %clang_cc1 -triple spirv64-unknown-unknown -fcuda-is-device -emit-llvm 
-o - %s | FileCheck %s
+struct x {
+  double b;
+  long a;
+};
+
+void testva(int n, ...) {
+  __builtin_va_list ap;
+  __builtin_va_start(ap, n);
+  struct x t = __builtin_va_arg(ap, struct x);
+  __builtin_va_list ap2;
+  __builtin_va_copy(ap2, ap);
+  int v = __builtin_va_arg(ap2, int);
+  __builtin_va_end(ap2);
+  __builtin_va_end(ap);
+}
+
+// CHECK:  call void @llvm.va_start.p4(ptr addrspace(4) %ap{{.*}})

jrtc27 wrote:

Use update_cc_test_checks.py?

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 commented:

Some minor comments, but otherwise would be good to see this upstream. We've 
had this downstream in CHERI LLVM for many years and never got round to 
upstreaming it.

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,22 @@
+// REQUIRES: spirv-registered-target

jrtc27 wrote:

Does it actually? Normally -emit-llvm works regardless of the enabled backends

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

[clang] [llvm] [CodeGen][LLVM] Make the `va_list` related intrinsics generic. (PR #85460)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/85460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

I guess my underlying point is that Arm's ACLE provides functions like 
__arm_rsr, but I'm not aware of them really being used, with inline assembly 
being the far more common alternative, so what's the real point of providing an 
interface that developers have already demonstrated they won't generally use?

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

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

You can just use `({ ... })` to achieve that same goal with inline assembly 
(and write doesn't even need that, you can do it with a single statement). I'm 
not convinced the intrinsics gain you anything.

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

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> > I support adding these builtins personally, but I think we need more 
> > discussions on the design. We can achieve the same thing via inline 
> > assemblies, that's true. But, from the compiler side, inline assemblies are 
> > kind of barriers, we can't do a lot of optimizations/reorderings if inline 
> > assemblies exist. If we make it a builtin, these limitations can be loosed 
> > I think.
> 
> Inline assembly is only a barrier to moving load/stores and other side 
> effecting instructions. And only if the inline assembly is marked volatile or 
> has "memory" clobber. It should not affect moving arithmetic. I think these 
> CSR intrinsics would also need to be barriers against load/stores and other 
> side effects to be the most conservative to access any CSR.

Yes, exactly; you have no clue what the semantics of the CSR are (if you did, 
you'd have a named intrinsic, like `__builtin_readcyclecounter()`) because it 
is just an arbitrary number.

Also, in what world do you need compiler optimisations around general CSR 
accesses? That's normally relatively cold performance-non-critical code...

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

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> > I have always been unconvinced that these are a good idea to have / add 
> > significant value over using inline assembly. IIRC Arm has them but nobody 
> > uses them?
> 
> Is this a comment about the general concept of builtins to produce specific 
> instructions or about these specific ones? For these ones, the patch isn't 
> something I materialized out of thin air just because I think it's nice to 
> have - it was in response to the very use case I described (from a library 
> writer). They had something like:
> 
> ```
> void __attribute__((always_inline)) set_csr(unsigned CSRNum, unsigned Val) {
> __asm__ volatile ...
> ```
> 
> Which works great if you're optimizing, but doesn't with -O0. Of course they 
> could write it as a macro, but that has all the pitfalls of function-style 
> macros.
> 
> Of course, if the consensus is to not provide these because of some reason, 
> I'm fine with that - I would just like to understand the reason for the 
> opposition to this.

If it’s not a constant integer for inline assembly then how would it magically 
be a constant integer for an intrinsic? The IR’s going to be the same with an 
alloca/store/load, no?

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

[clang] [DRAFT][RISCV] Emit arch string macro to facilitate ASM programming (PR #85063)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Attributes are added automatically, unless you override it with your own 
.attribute arch.

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

[clang] [clang] Define SwiftInfo for RISCVTargetCodeGenInfo (PR #82152)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

What purpose does this serve if swiftcall doesn't work? Given the tests only 
test that you can produce IR from Clang, that suggests that it doesn't actually 
do anything useful?.. (And if it does do something useful, *that* should be 
being tested)

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

[clang] [llvm] [RISC-V] Add CSR read/write builtins (PR #85091)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

I have always been unconvinced that these are a good idea to have / add 
significant value over using inline assembly. IIRC Arm has them but nobody uses 
them?

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

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 dismissed 
https://github.com/llvm/llvm-project/pull/83896
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> @jrtc27 does this look better now?

Yes; thanks

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

[clang] [RISCV][Clang] Added builtin support for experimental Zimop extension (PR #79971)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Surely we should instead be defining intrinsics with actual names for the 
operations we know about? What's the actual use case for needing an arbitrary 
unnamed one?

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

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> By the way, is there any plan to support `CFLUSH.I.L1` in the future?

Flushing the instruction cache doesn't make sense given it can never be dirty. 
Invalidating/discarding does, but that's just what fence.i is doing?

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

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

[Jessica Clarke via cfe-commits]

@@ -807,6 +807,9 @@ def FeatureStdExtSsccptr
 : SubtargetFeature<"ssccptr", "HasStdExtSsccptr", "true",
"'Ssccptr' (Main memory supports page table reads)", 
[]>;
 
+def FeatureStdExtSscofpmf
+: SubtargetFeature<"sscofpmf", "HasStdExtSscofpmf", "true",
+   "'Sscofpmf' (Count Overflow and Mode-Based Filtering)", 
[]>;

jrtc27 wrote:

Missing newline; it's not grouped with S*counterenw

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

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

[Jessica Clarke via cfe-commits]

@@ -234,7 +235,7 @@ Supported
 
 .. _riscv-profiles-extensions-note:
 
-``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, 
``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, 
``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscounterenw``, ``Ssstateen``, 
``Ssstrict``, ``Sstvala``, ``Sstvecd``, ``Ssu64xl``, ``Svade``, ``Svbare``
+``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, 
``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, 
``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscofpmf``, ``Sscounterenw``, 
``Ssstateen``, ``Ssstrict``, ``Sstvala``, ``Sstvecd``, ``Ssu64xl``, ``Svade``, 
``Svbare``
   These extensions are defined as part of the `RISC-V Profiles specification 
`__.  They do not 
introduce any new features themselves, but instead describe existing hardware 
features.

jrtc27 wrote:

Ssstateen is also somewhat debatable; it's not a real extension, only defined 
by the profiles spec, yet it's also defined in terms of being the S-mode subset 
of Smstateen. Feels like it really should have been defined like e.g 
Smaia+Ssaia are defined. But it's not entirely like these other extensions, 
because it also adds its own features, just a subset of Smstateen.

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

[clang] [llvm] [RISCV] Add support of Sscofpmf (PR #83831)

[Jessica Clarke via cfe-commits]

@@ -234,7 +235,7 @@ Supported
 
 .. _riscv-profiles-extensions-note:
 
-``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, 
``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, 
``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscounterenw``, ``Ssstateen``, 
``Ssstrict``, ``Sstvala``, ``Sstvecd``, ``Ssu64xl``, ``Svade``, ``Svbare``
+``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, 
``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, 
``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscofpmf``, ``Sscounterenw``, 
``Ssstateen``, ``Ssstrict``, ``Sstvala``, ``Sstvecd``, ``Ssu64xl``, ``Svade``, 
``Svbare``
   These extensions are defined as part of the `RISC-V Profiles specification 
`__.  They do not 
introduce any new features themselves, but instead describe existing hardware 
features.

jrtc27 wrote:

That's not true of Ssocfpmf? It adds new bits to mhpmevent, adds the new LCOF 
interrupt type (reflected in xip and xie) and adds a new scountovf CSR.

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

[clang] [llvm] [RISCV] Add back SiFive's cdiscard.d.l1 and cflush.d.l1 instructions. (PR #83896)

[Jessica Clarke via cfe-commits]

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

These need the vendor "sf." prefix

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

[clang] [clang-tools-extra] [compiler-rt] [flang] [libclc] [libcxx] [lld] [lldb] [llvm] [NFC] Remove trailing whitespace across all non-test related files (PR #82838)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Also this is the kind of commit that should really be done by a core trusted 
member of the community. It's way too easy to hide something nefarious (not 
that I'm accusing you of that, just that we always need to be vigilant) in an 
8k+ diff, and it's not much fun to review that code. Also it's best when people 
provide the scripts used to do these kinds of mass changes; that (a) lets 
people verify what you did by auditing the script and running it themselves (b) 
lets downstreams easily perform the same change on their forks.

The fact that this is a +8347 -8382 diff also confuses me; I would expect the 
number of lines to remain constant, but maybe you're including trailing blank 
lines as trailing whitespace?..

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

[clang] [clang][CodeGen] Emit atomic IR in place of optimized libcalls. (PR #73176)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Part of that confusion comes from SPARC's own naming. V9 is the CPU, but a V9 
CPU being used for 32-bit code is called V8+...

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

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

That's fair. I just imagine this is going to result in people forgetting about 
the underlying issue and adding their own patchwork fixes to work around it in 
their targets, so it would be a nice motivation to fix it properly.

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

[clang] [lld] [llvm] [llvm-driver] Fix usage of `InitLLVM` on Windows (PR #76306)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

llvm-driver-template.cpp.in is what should be generating the real main for 
Clang (and call clang_main), and that was patched in this commit.

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

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> > I just noticed we only set EF_RISCV_RVC based on C, and not Zca. Is that a 
> > bug?
> 
> I think so; binutils sets it for both.

(R_RISCV_ALIGN can probably fail if you don't, I don't think it's just a 
missing optimisation)

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

[clang] [RISCV] Add canonical ISA string as Module metadata in IR. (PR #80760)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> I just noticed we only set EF_RISCV_RVC based on C, and not Zca. Is that a 
> bug?

I think so; binutils sets it for both.

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

[clang] [RISCV] Add -march string as Module metadata in IR. (PR #80760)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

My thoughts on this in the past have been:

1. target-abi should really be a target-independent thing we record; its 
meaning depends on the target, but the ABI exists throughout LLVM as a concept 
regardless of the target
2. module-level target features in general likely should be the thing we 
record, corresponding to the subtarget, not some target-dependent 
representation, as, again, all targets have that throughout LLVM and just use 
them to a greater or lesser extent

RISC-V is the most sensitive to this, but it's just a symptom of not having the 
general mechanism in place, and I'm not a huge fan of adding ad-hoc stuff 
specific to RISC-V rather than addressing the underlying problem. Other targets 
just care less upstream today so get away with this lack of information in 
practice, but that won't always true (e.g. I believe we need this information 
on Morello (CHERI+AArch64 prototype) downstream, not just for CHERI-RISC-V).

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

[llvm] [clang-tools-extra] [mlir] [libc] [libcxx] [lldb] [libcxxabi] [clang] [lld] [compiler-rt] [flang] [Mips] Fix unable to handle inline assembly ends with compat-branch o… (PR #77291)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

What assembly does GCC emit, and how does GNU as deal with that assembly? That 
is, how do those two tools interact in the GNU world when dealing with 
forbidden slots?

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

[clang-tools-extra] [llvm] [clang] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

[Jessica Clarke via cfe-commits]

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error<
 "%select{expected|'expected-no-diagnostics'}0 directive cannot follow "
 "%select{'expected-no-diagnostics' directive|other expected directives}0">;

jrtc27 wrote:

This looks like it needs templating?

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

[clang-tools-extra] [llvm] [clang] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

[Jessica Clarke via cfe-commits]

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error<
 "%select{expected|'expected-no-diagnostics'}0 directive cannot follow "
 "%select{'expected-no-diagnostics' directive|other expected directives}0">;
 def err_verify_no_directives : Error<
-"no expected directives found: consider use of 'expected-no-diagnostics'">;
+"no expected directives found: consider use of '%0-no-diagnostics'">;

jrtc27 wrote:

I guess elsewhere we refer to them as expected diagnostics, it's only in single 
quotes that we intend it to match the source?

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

[clang] [clang-tools-extra] [llvm] [Clang] Fix : More Detailed "No expected directives found" (PR #78338)

[Jessica Clarke via cfe-commits]

@@ -179,7 +179,7 @@ def err_verify_invalid_no_diags : Error<
 "%select{expected|'expected-no-diagnostics'}0 directive cannot follow "
 "%select{'expected-no-diagnostics' directive|other expected directives}0">;
 def err_verify_no_directives : Error<
-"no expected directives found: consider use of 'expected-no-diagnostics'">;
+"no expected directives found: consider use of '%0-no-diagnostics'">;

jrtc27 wrote:

```suggestion
"no %0 directives found: consider use of '%0-no-diagnostics'">;
```
no?

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

[llvm] [clang] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

[Jessica Clarke via cfe-commits]

@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating 
the runtime into
 the operating system should be preferred since otherwise all thread creation
 and destruction would need to be intercepted by the application.
 
-The instrumentation makes use of the platform register ``x18`` on AArch64 and
-``x3`` (``gp``) on RISC-V. For simplicity we will refer to this as the
-``SCSReg``. On some platforms, ``SCSReg`` is reserved, and on others, it is
-designated as a scratch register.  This generally means that any code that may
-run on the same thread as code compiled with ShadowCallStack must either target
+The instrumentation makes use of the platform register ``x18`` on AArch64,
+``x3`` (``gp``) on RISC-V with software shadow stack and ``ssp`` on RISC-V with
+hardware shadow stack, which needs `Zicfiss`_ and 
``-mno-forced-sw-shadow-stack``

jrtc27 wrote:

(Though you still have the related problem that some older LLVM may not know 
that OS version X supports it, and still default it to off)

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

[llvm] [clang] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

[Jessica Clarke via cfe-commits]

@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating 
the runtime into
 the operating system should be preferred since otherwise all thread creation
 and destruction would need to be intercepted by the application.
 
-The instrumentation makes use of the platform register ``x18`` on AArch64 and
-``x3`` (``gp``) on RISC-V. For simplicity we will refer to this as the
-``SCSReg``. On some platforms, ``SCSReg`` is reserved, and on others, it is
-designated as a scratch register.  This generally means that any code that may
-run on the same thread as code compiled with ShadowCallStack must either target
+The instrumentation makes use of the platform register ``x18`` on AArch64,
+``x3`` (``gp``) on RISC-V with software shadow stack and ``ssp`` on RISC-V with
+hardware shadow stack, which needs `Zicfiss`_ and 
``-mno-forced-sw-shadow-stack``

jrtc27 wrote:

I think it's really (non-Android) Linux that's the odd one out due to not 
having a version number in the triple?

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

[clang] [llvm] [RISCV] Add experimental support of Zaamo and Zalrsc (PR #77424)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

I guess Zaamo + Zacas is technically a way one could implement atomics without 
LR/SC?

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

[clang] [llvm] [RISCV] Add support for Smepmp 1.0 (PR #78489)

[Jessica Clarke via cfe-commits]

@@ -722,6 +722,11 @@ def FeatureStdExtSsaia
"'Ssaia' (Advanced Interrupt Architecture Supervisor "
"Level)", []>;
 
+def FeatureStdExtSmepmp
+: SubtargetFeature<"smepmp", "HasStdExtSmepmp", "true",
+   "'Smepmp' (PMP Enhancements for memory access and "

jrtc27 wrote:

This seems pretty clunky, what's wrong with just "Enhanced PMP" / "Enhanced 
Physical Memory Protection"? That's what it stands for after all...

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

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Though please make sure to update the PR message (which will become the commit 
message) before merging, as it's no longer accurate

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

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

[Jessica Clarke via cfe-commits]

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

Thanks, this looks better now

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

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/71313
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][docs] Improve "Obtaining Clang" section (PR #71313)

[Jessica Clarke via cfe-commits]

@@ -22,8 +22,8 @@ started guide `_.
 
 .. code-block:: console
 
-  cd ~/clang-llvm
-  git clone https://github.com/llvm/llvm-project.git
+  mkdir ~/clang-llvm && cd ~/clang-llvm
+  git clone https://github.com/llvm/llvm-project.git .

jrtc27 wrote:

Given the:
```
  cd ~/clang-llvm
  git clone git://cmake.org/stage/cmake.git
```
this isn't a good idea. Better to clone it to an llvm-project subdirectory 
(i.e. drop the .) and alter later steps.

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

[llvm] [clang] [SPARC] Support reserving arbitrary general purpose registers (PR #74927)

[Jessica Clarke via cfe-commits]

@@ -1125,6 +1130,10 @@ Register SparcTargetLowering::getRegisterByName(const 
char* RegName, LLT VT,
 .Case("g4", SP::G4).Case("g5", SP::G5).Case("g6", SP::G6).Case("g7", 
SP::G7)
 .Default(0);
 
+  const SparcRegisterInfo *TRI = Subtarget->getRegisterInfo();
+  if (!TRI->isReservedReg(MF, Reg))
+Reg = 0;

jrtc27 wrote:

```not --crash```

Though  you need to be sure it will deterministically crash even in 
non-assertions release builds

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

[mlir] [polly] [clang] [libunwind] [flang] [lld] [lldb] [compiler-rt] [clang-tools-extra] [libcxxabi] [libcxx] [openmp] [libc] [llvm] Make clang report invalid target versions. (PR #75373)

[Jessica Clarke via cfe-commits]

@@ -786,4 +786,7 @@ def warn_android_unversioned_fallback : Warning<
   " directories will not be used in Clang 19. Provide a versioned directory"
   " for the target version or lower instead.">,
   InGroup>;
+
+def err_android_version_invalid : Error<
+  "Version %0 in triple %1 is invalid.">;

jrtc27 wrote:

* Elsewhere we say "target triple"
* Repeating the version seems a bit ugly?

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

[clang] [llvm] [SPARC] Support reserving arbitrary general purpose registers (PR #74927)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Doesn’t the ABI require you to emit magic STT_REGISTER or whatever they are 
symbols to mark this?

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

[clang] [llvm] [RISCV] Always emit relocations for resolved symbols and relax (PR #73793)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> Also, we cannot trust Subtarget features here, because it may be empty in 
> case of LTO codegen, preventing relaxations.

And that's the problem. It's vital that we have the information. Anything else 
is just a hack that papers over the fundamental issue.

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

[clang] [llvm] [RISCV] Always emit relocations for resolved symbols and relax (PR #73793)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

As far as I can tell this is pointless. If you want relaxation you need 
R_RISCV_RELAX and R_RISC_ALIGN relocations to be emitted. If you don't want 
relaxation you don't need these. Therefore it seems like all this does is emit 
a whole bunch of useless relocations for the case when you're not enabling 
relaxation at compile time and thus cannot possibly enable it at link time?

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

[clang-tools-extra] [clang] [llvm] [libc] [compiler-rt] [lld] [flang] [lldb] [libcxx] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/71771
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [libc] [clang-tools-extra] [libcxx] [lldb] [llvm] [compiler-rt] [lld] [flang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

[Jessica Clarke via cfe-commits]

@@ -286,7 +286,33 @@ 
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier ,
   lmKind = LengthModifier::AsInt3264;
   break;
 case 'w':
-  lmKind = LengthModifier::AsWide; ++I; break;
+  ++I;
+  if (I == E) return false;
+  if (*I == 'f') {
+lmKind = LengthModifier::AsWideFast;
+++I;
+  } else {
+lmKind = LengthModifier::AsWide;
+  }
+
+  if (I == E) return false;
+  int s = 0;
+  while (unsigned(*I - '0') <= 9) {
+s = 10 * s + unsigned(*I - '0');
+++I;
+  }
+
+  // s == 0 is MSVCRT case, like l but only for c, C, s, S, or Z on windows
+  // s != 0 for b, d, i, o, u, x, or X when a size followed(like 8, 16, 32 
or 64)
+  if (s != 0) {
+std::set supported_list {8, 16, 32, 64};

jrtc27 wrote:

FreeBSD patches out Clang’s stdint.h and uses its own, which doesn’t have any 
of those peculiar types

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

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 closed https://github.com/llvm/llvm-project/pull/65214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Rebased to verify CI still passes before merging (thanks Aaron for the reverse 
ping)

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

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

[Jessica Clarke via cfe-commits]

@@ -21,9 +21,6 @@
 
 /* C23 7.20.1 Defines several macros for performing checked integer 
arithmetic*/
 
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
-#define __STDC_VERSION_STDCKDINT_H__ 202311L

jrtc27 wrote:

This needs to stay, `__STDC_VERSION_STDCKDINT_H__` is defined by C23, not just 
something Clang invented

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

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

[Jessica Clarke via cfe-commits]

@@ -177,7 +177,7 @@ C23 Feature Support
 - Clang now supports ``N3007 Type inference for object definitions``.
 
 - Clang now supports  which defines several macros for 
performing
-  checked integer arithmetic.
+  checked integer arithmetic. And it is also exposed in pre-C23 modes.

jrtc27 wrote:

Don't start a sentence with And

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

[clang] Update stdckdint.h and make it available in pre-C23 modes. (PR #69649)

[Jessica Clarke via cfe-commits]

@@ -33,8 +33,3 @@
 #error "__STDC_VERSION_STDINT_H__ not defined"
 // expected-error@-1 {{"__STDC_VERSION_STDINT_H__ not defined"}}
 #endif
-
-#include 
-#ifndef __STDC_VERSION_STDCKDINT_H__
-#error "__STDC_VERSION_STDCKDINT_H__ not defined"

jrtc27 wrote:

And this test needs to stay

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

[clang] [RISCV][LLD] Add RISCV zcmt optimise in linker relaxation (PR #68551)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> > > This patch is moved from https://reviews.llvm.org/D134600
> > 
> > 
> > Why? That loses all the context in the Phabricator review. Keep the review 
> > there.
> 
> yes, I will keep it there.
> 
> But the [Phabricator shutdown 
> timeline](https://discourse.llvm.org/t/update-on-github-pull-requests/71540) 
> said that
> 
> > Phabricator becomes read-only after October 1
> 
> So I thought it may means we can't add comments or update it? That's why I 
> moved it from Phabricator.
> 
> If you mean we still can review it at Phabricator, I will close this 
> pr. )

Scroll down the thread and you will find 
https://discourse.llvm.org/t/update-on-github-pull-requests/71540/124. There's 
consensus that Phabricator will remain usable for existing revisions for a 
while longer for this specific kind of situation, and that migrating revisions 
off of it loses valuable context and should be avoided.

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

[clang-tools-extra] [RISCV][LLD] Add RISCV zcmt optimise in linker relaxation (PR #68551)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> This patch is moved from https://reviews.llvm.org/D134600

Why? That loses all the context in the Phabricator review. Keep the review 
there.

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

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Oh and https://clang.llvm.org/docs/CommandGuide/clang.html.

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

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

I mean places like https://clang.llvm.org/docs/ClangCommandLineReference.html 
and https://clang.llvm.org/docs/UsersManual.html#command-line-options.

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

[clang] Add -fkeep-system-includes modifier for -E (PR #67684)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Its limitations, i.e. how in various cases it can break or change correct code, 
need to be documented somewhere alongside the option (ideally a disclaimer in 
--help's output and a longer explanation in the rendered documentation).

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

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

[Jessica Clarke via cfe-commits]

@@ -3362,6 +3362,7 @@ Address 
CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction ,
   break;
 case OMPAllocateDeclAttr::OMPLargeCapMemAlloc:
 case OMPAllocateDeclAttr::OMPCGroupMemAlloc:
+  AS = 
getLangASFromTargetAS(CGF.CGM.getModule().getDataLayout().getDefaultGlobalsAddressSpace());

jrtc27 wrote:

Running clang-format on your commit (but just your commit, and only accepting 
changes to the lines you've changed, i.e. just this line) to fix this doesn't 
need pre-commit review

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

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

[Jessica Clarke via cfe-commits]

@@ -3362,6 +3362,7 @@ Address 
CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction ,
   break;
 case OMPAllocateDeclAttr::OMPLargeCapMemAlloc:
 case OMPAllocateDeclAttr::OMPCGroupMemAlloc:
+  AS = 
getLangASFromTargetAS(CGF.CGM.getModule().getDataLayout().getDefaultGlobalsAddressSpace());

jrtc27 wrote:

This line is way too long compared to the 80 char line limit

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

[clang] [Clang][OpenMP] Clang adding the addrSpace according to DataLayout fix (PR #65483)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

The title isn't a proper commit subject, the tense/mood doesn't make sense

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

[clang] [RISCV] Support target attribute for function (PR #65948)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

Please do not move from Phabricator to GitHub for existing changes, it loses 
all the context that was built up from previous reviews. New changes should be 
proposed on GitHub but existing ones should stay put.

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

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

> ", where the aka will be skipped" in the commit message still doesn't make 
> sense to me , otherwise lgtm

Comments in Clang's ASTDiagnostic use "aka" and "aka clause" synonymously, 
referring to the parenthesised clause in `'foo' (aka 'bar')` that is sometimes 
printed in diagnostics. That clause is never printed if `foo` and `bar` are the 
same string, even if `foo` is sugared.

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

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 review_requested 
https://github.com/llvm/llvm-project/pull/65214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [AST] Only dump desugared type when visibly different (PR #65214)

[Jessica Clarke via cfe-commits]

jrtc27 wrote:

I've added a release note (with hopefully valid reST syntax) and made the 
source comment less terse as requested

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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v -fopenmp %s

jrtc27 wrote:

Commenting here rather than the commit: What happened to -fsyntax-only -verify?

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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 review_requested 
https://github.com/llvm/llvm-project/pull/65778
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v \
+// RUN:   -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify 
+// REQUIRES: riscv-registered-target
+// expected-no-diagnostics

jrtc27 wrote:

```suggestion

// expected-no-diagnostics

```

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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

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


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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v \
+// RUN:   -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify 

jrtc27 wrote:

-disable-O0-optnone is pointless unless you're generating code *and* piping it 
to opt, but you're doing neither. Similarly -o - is pointless with 
-fsyntax-only -verify given you're not producing output (except from -verify 
itself directly to stdio).

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

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/65778
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][RISCV] Use Decl for checkRVVTypeSupport (PR #65778)

[Jessica Clarke via cfe-commits]

@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +v \
+// RUN:   -disable-O0-optnone -o - -fsyntax-only -fopenmp %s -verify 
+// REQUIRES: riscv-registered-target
+// expected-no-diagnostics
+#include 

jrtc27 wrote:

This is shipped by Clang not the system

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

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

[Jessica Clarke via cfe-commits]

@@ -322,6 +327,8 @@ bool 
RISCVTargetInfo::handleTargetFeatures(std::vector ,
   if (ISAInfo->hasExtension("zfh") || ISAInfo->hasExtension("zhinx"))
 HasLegalHalfType = true;
 
+  FastUnalignedAccess = llvm::is_contained(Features, "+unaligned-scalar-mem");

jrtc27 wrote:

What about --target-features +unaligned-scalar-mem --target-features 
-unaligned-scalar-mem? Unless this has been canonicalised you don't know it's 
not overridden.

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

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

[Jessica Clarke via cfe-commits]

https://github.com/jrtc27 edited https://github.com/llvm/llvm-project/pull/65756
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [RISCV] Support predefined marcro __riscv_misaligned_{fast,avoid}. (PR #65756)

[Jessica Clarke via cfe-commits]

@@ -1220,3 +1220,15 @@
 // RUN: -march=rv64i_zve32x_zvkt1p0 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZVKT-EXT %s
 // CHECK-ZVKT-EXT: __riscv_zvkt 100{{$}}
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32i -x c -E -dM %s \

jrtc27 wrote:

To be fair, the tests in this file are currently %clang. I would argue we 
should be consistent, which either means %clang here or someone converting the 
others to %clang_cc1 (so long as those still make sense as cc1 tests)

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

[clang] [clang][CodeGen] Simplify code based on opaque pointers (PR #65624)

[Jessica Clarke via cfe-commits]

@@ -51,14 +51,11 @@ struct CodeGenTypeCache {
 llvm::IntegerType *PtrDiffTy;
   };
 
-  /// void* in address space 0
+  /// void*, void** in address space 0
   union {
+llvm::PointerType *UnqualPtrTy;

jrtc27 wrote:

(Presumably the IR type's nomenclature has its origins in C's language)

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