[clang] 5fee693 - [AST] Use PrintingPolicy for format string diagnosis

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2020-04-28T23:43:48+01:00
New Revision: 5fee6936b8b241b36fadaf0dcd962e9c9adc8a69

URL: 
https://github.com/llvm/llvm-project/commit/5fee6936b8b241b36fadaf0dcd962e9c9adc8a69
DIFF: 
https://github.com/llvm/llvm-project/commit/5fee6936b8b241b36fadaf0dcd962e9c9adc8a69.diff

LOG: [AST] Use PrintingPolicy for format string diagnosis

Summary:
This is a small improvement for OpenCL diagnostics, but is also useful
for our CHERI fork, as our __capability qualifier is suppressed from
diagnostics when all pointers are capabilities, only being used when pointers
need to be explicitly opted-in to being capabilities.

Reviewers: rsmith, Anastasia, aaron.ballman

Reviewed By: Anastasia, aaron.ballman

Subscribers: aaron.ballman, arichardson, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78777

Added: 


Modified: 
clang/lib/AST/FormatString.cpp
clang/test/SemaOpenCL/printf-format-strings.cl

Removed: 




diff  --git a/clang/lib/AST/FormatString.cpp b/clang/lib/AST/FormatString.cpp
index fcc0b3b11e25..e9f6b88631af 100644
--- a/clang/lib/AST/FormatString.cpp
+++ b/clang/lib/AST/FormatString.cpp
@@ -539,7 +539,7 @@ QualType ArgType::getRepresentativeType(ASTContext &C) 
const {
 }
 
 std::string ArgType::getRepresentativeTypeName(ASTContext &C) const {
-  std::string S = getRepresentativeType(C).getAsString();
+  std::string S = getRepresentativeType(C).getAsString(C.getPrintingPolicy());
 
   std::string Alias;
   if (Name) {

diff  --git a/clang/test/SemaOpenCL/printf-format-strings.cl 
b/clang/test/SemaOpenCL/printf-format-strings.cl
index 0cfeeb135796..6cdfc7e60b37 100644
--- a/clang/test/SemaOpenCL/printf-format-strings.cl
+++ b/clang/test/SemaOpenCL/printf-format-strings.cl
@@ -65,8 +65,8 @@ kernel void format_v4f64(half4 arg_h, float4 arg_f, double4 
arg_d)
 
 kernel void format_v4f16(half4 arg_h, float4 arg_f, double4 arg_d)
 {
-  printf("%v4hf\n", arg_d); // expected-warning{{format specifies type '__fp16 
__attribute__((ext_vector_type(4)))' but the argument has type 'double4' 
(vector of 4 'double' values)}}
-  printf("%v4hf\n", arg_f); // expected-warning{{format specifies type '__fp16 
__attribute__((ext_vector_type(4)))' but the argument has type 'float4' (vector 
of 4 'float' values)}}
+  printf("%v4hf\n", arg_d); // expected-warning{{format specifies type 'half 
__attribute__((ext_vector_type(4)))' but the argument has type 'double4' 
(vector of 4 'double' values)}}
+  printf("%v4hf\n", arg_f); // expected-warning{{format specifies type 'half 
__attribute__((ext_vector_type(4)))' but the argument has type 'float4' (vector 
of 4 'float' values)}}
   printf("%v4hf\n", arg_h);
 }
 



___
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] [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 &FS,
   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-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] [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] [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

[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

[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

[clang] 0e79a94 - [Utils] Support class template specializations in update_cc_test_checks

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2021-07-28T16:03:41+01:00
New Revision: 0e79a94836d7127a87c36fdca43ffaf6a17d8964

URL: 
https://github.com/llvm/llvm-project/commit/0e79a94836d7127a87c36fdca43ffaf6a17d8964
DIFF: 
https://github.com/llvm/llvm-project/commit/0e79a94836d7127a87c36fdca43ffaf6a17d8964.diff

LOG: [Utils] Support class template specializations in update_cc_test_checks

ClassTemplateSpecializationDecl not within a ClassTemplateDecl
represents an explicit instatiation of a template and so should be
handled as if it were a normal CXXRecordDecl. Unfortunately, having an
equivalent for FunctionTemplateDecl remains a TODO in ASTDumper's
VisitFunctionTemplateDecl, with all the explicit instantiations just
being emitted inside the FunctionTemplateDecl along with all the other
specializations, meaning we can't easily support explicit function
instantiations in update_cc_test_checks.

Reviewed By: arichardson

Differential Revision: https://reviews.llvm.org/D106243

Added: 

clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp

clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
clang/test/utils/update_cc_test_checks/explicit-template-instantiation.test

Modified: 
llvm/utils/update_cc_test_checks.py

Removed: 




diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp
 
b/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp
new file mode 100644
index 0..859e0c73ec119
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+
+template 
+struct Foo {
+private:
+  T x;
+
+public:
+  Foo(T x) : x(x) {}
+  ~Foo() {}
+
+  T get() { return x; }
+  void set(T _x) { x = _x; }
+};
+
+template 
+struct Bar {
+private:
+  struct Foo foo;
+
+public:
+  Bar(T x) : foo(x) {}
+  ~Bar() {}
+
+  T get() { return foo.get(); }
+  void set(T _x) { foo.set(_x); }
+};
+
+template 
+struct Baz : Foo {
+public:
+  Baz(T x) : Foo(x) {}
+  ~Baz() {}
+};
+
+// These two specializations should generate lines for all of Foo's methods.
+
+template struct Foo;
+
+template struct Foo;
+
+// This should not generate lines for the implicit specialization of Foo, but
+// should generate lines for the explicit specialization of Bar.
+
+template struct Bar;
+
+// This should not generate lines for the implicit specialization of Foo, but
+// should generate lines for the explicit specialization of Baz.
+
+template struct Baz;

diff  --git 
a/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
 
b/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
new file mode 100644
index 0..fc132c0f7fa79
--- /dev/null
+++ 
b/clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
@@ -0,0 +1,190 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple=x86_64-unknown-linux-gnu -emit-llvm -o - %s | 
FileCheck %s
+
+template 
+struct Foo {
+private:
+  T x;
+
+public:
+  Foo(T x) : x(x) {}
+  ~Foo() {}
+
+  T get() { return x; }
+  void set(T _x) { x = _x; }
+};
+
+template 
+struct Bar {
+private:
+  struct Foo foo;
+
+public:
+  Bar(T x) : foo(x) {}
+  ~Bar() {}
+
+  T get() { return foo.get(); }
+  void set(T _x) { foo.set(_x); }
+};
+
+template 
+struct Baz : Foo {
+public:
+  Baz(T x) : Foo(x) {}
+  ~Baz() {}
+};
+
+// These two specializations should generate lines for all of Foo's methods.
+
+// CHECK-LABEL: @_ZN3FooIcEC1Ec(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca %struct.Foo*, align 8
+// CHECK-NEXT:[[X_ADDR:%.*]] = alloca i8, align 1
+// CHECK-NEXT:store %struct.Foo* [[THIS:%.*]], %struct.Foo** 
[[THIS_ADDR]], align 8
+// CHECK-NEXT:store i8 [[X:%.*]], i8* [[X_ADDR]], align 1
+// CHECK-NEXT:[[THIS1:%.*]] = load %struct.Foo*, %struct.Foo** 
[[THIS_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i8, i8* [[X_ADDR]], align 1
+// CHECK-NEXT:call void @_ZN3FooIcEC2Ec(%struct.Foo* nonnull align 1 
dereferenceable(1) [[THIS1]], i8 signext [[TMP0]])
+// CHECK-NEXT:ret void
+//
+// CHECK-LABEL: @_ZN3FooIcED1Ev(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca %struct.Foo*, align 8
+// CHECK-NEXT:store %struct.Foo* [[THIS:%.*]], %struct.Foo** 
[[THIS_ADDR]], align 8
+// CHECK-NEXT:[[THIS1:%.*]] = load %struct.Foo*, %struct.Foo** 
[[THIS_ADDR]], align 8
+// CHECK-NEXT:call void @_ZN3FooIcED2Ev(%struct.Foo* nonnull align 1 
dereferenceable(1) [[THIS1]]) #[[ATTR2:[0-9]+]]
+// CHECK-NEXT:ret void
+//
+// CHECK-LABEL: @_ZN3FooIcE3getEv(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[THIS_ADDR:%.*]] = alloca

[clang] 40080e7 - [Clang interpreter] Avoid storing pointers at unaligned locations

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2021-07-28T16:03:41+01:00
New Revision: 40080e7e7f42857c8edac4a53e476a68563f1a98

URL: 
https://github.com/llvm/llvm-project/commit/40080e7e7f42857c8edac4a53e476a68563f1a98
DIFF: 
https://github.com/llvm/llvm-project/commit/40080e7e7f42857c8edac4a53e476a68563f1a98.diff

LOG: [Clang interpreter] Avoid storing pointers at unaligned locations

The Clang interpreter's bytecode uses a packed stream of bytes
representation, but also wants to have some opcodes take pointers as
arguments, which are currently embedded in the bytecode directly.

However, CHERI, and thus Arm's upcoming experimental Morello prototype,
provide spatial memory safety for C/C++ by implementing language-level
(and sub-language-level) pointers as capabilities, which track bounds,
permissions and validity in hardware. This uses tagged memory with a
single tag bit at every capability-aligned address, and so storing
pointers to unaligned addresses results in the tag being stripped,
leading to a tag fault when the pointer is ultimately dereferenced at a
later point.

In order to support a stricter C/C++ implementation like CHERI, we no
longer store pointers directly in the bytecode, instead storing them in
a table and embedding the index in the bytecode.

Reviewed By: nand

Differential Revision: https://reviews.llvm.org/D97606

Added: 


Modified: 
clang/lib/AST/Interp/ByteCodeEmitter.cpp
clang/lib/AST/Interp/Disasm.cpp
clang/lib/AST/Interp/Interp.h
clang/lib/AST/Interp/Program.cpp
clang/lib/AST/Interp/Program.h
clang/lib/AST/Interp/Source.h
clang/utils/TableGen/ClangOpcodesEmitter.cpp

Removed: 




diff  --git a/clang/lib/AST/Interp/ByteCodeEmitter.cpp 
b/clang/lib/AST/Interp/ByteCodeEmitter.cpp
index 7a4569820a1d1..a69b23fd613cd 100644
--- a/clang/lib/AST/Interp/ByteCodeEmitter.cpp
+++ b/clang/lib/AST/Interp/ByteCodeEmitter.cpp
@@ -11,6 +11,7 @@
 #include "Opcode.h"
 #include "Program.h"
 #include "clang/AST/DeclCXX.h"
+#include 
 
 using namespace clang;
 using namespace clang::interp;
@@ -122,29 +123,48 @@ bool ByteCodeEmitter::bail(const SourceLocation &Loc) {
   return false;
 }
 
+/// Helper to write bytecode and bail out if 32-bit offsets become invalid.
+/// Pointers will be automatically marshalled as 32-bit IDs.
+template 
+static std::enable_if_t::value, void>
+emit(Program &P, std::vector &Code, const T &Val, bool &Success) {
+  size_t Size = sizeof(Val);
+  if (Code.size() + Size > std::numeric_limits::max()) {
+Success = false;
+return;
+  }
+
+  const char *Data = reinterpret_cast(&Val);
+  Code.insert(Code.end(), Data, Data + Size);
+}
+
+template 
+static std::enable_if_t::value, void>
+emit(Program &P, std::vector &Code, const T &Val, bool &Success) {
+  size_t Size = sizeof(uint32_t);
+  if (Code.size() + Size > std::numeric_limits::max()) {
+Success = false;
+return;
+  }
+
+  uint32_t ID = P.getOrCreateNativePointer(Val);
+  const char *Data = reinterpret_cast(&ID);
+  Code.insert(Code.end(), Data, Data + Size);
+}
+
 template 
 bool ByteCodeEmitter::emitOp(Opcode Op, const Tys &... Args, const SourceInfo 
&SI) {
   bool Success = true;
 
-  /// Helper to write bytecode and bail out if 32-bit offsets become invalid.
-  auto emit = [this, &Success](const char *Data, size_t Size) {
-if (Code.size() + Size > std::numeric_limits::max()) {
-  Success = false;
-  return;
-}
-Code.insert(Code.end(), Data, Data + Size);
-  };
-
   /// The opcode is followed by arguments. The source info is
   /// attached to the address after the opcode.
-  emit(reinterpret_cast(&Op), sizeof(Opcode));
+  emit(P, Code, Op, Success);
   if (SI)
 SrcMap.emplace_back(Code.size(), SI);
 
   /// The initializer list forces the expression to be evaluated
   /// for each argument in the variadic template, in order.
-  (void)std::initializer_list{
-  (emit(reinterpret_cast(&Args), sizeof(Args)), 0)...};
+  (void)std::initializer_list{(emit(P, Code, Args, Success), 0)...};
 
   return Success;
 }

diff  --git a/clang/lib/AST/Interp/Disasm.cpp b/clang/lib/AST/Interp/Disasm.cpp
index c1c18f832d4fa..36adbe296b0cc 100644
--- a/clang/lib/AST/Interp/Disasm.cpp
+++ b/clang/lib/AST/Interp/Disasm.cpp
@@ -21,6 +21,19 @@
 using namespace clang;
 using namespace clang::interp;
 
+template 
+inline std::enable_if_t::value, T> ReadArg(Program &P,
+   CodePtr OpPC) {
+  return OpPC.read();
+}
+
+template 
+inline std::enable_if_t::value, T> ReadArg(Program &P,
+  CodePtr OpPC) {
+  uint32_t ID = OpPC.read();
+  return reinterpret_cast(P.getNativePointer(ID));
+}
+
 LLVM_DUMP_METHOD void Function::dump() const { dump(llvm::errs()); }
 
 LLVM_DUMP_METHOD void Function::dump(llvm::raw_ostream &OS) const {

diff  --git a/clang/lib/AST/Interp/Interp.h b/clang/lib/AST/Int

[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] [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] [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] [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] [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:

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 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] [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]

@@ -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 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
+// 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]

@@ -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 {

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]

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]

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]

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]

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]

@@ -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] [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 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] [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:

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] [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] [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] [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:

> @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] [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] [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] [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] [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 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]

@@ -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

[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] [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] [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

[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

[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

[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-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] [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

[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]

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]

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] [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] [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] 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] 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]

@@ -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] [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] [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] 788c7d2 - [clang][docs] Fix documentation of -O

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2020-09-17T13:44:01+01:00
New Revision: 788c7d2ec11dfc868a5b03478c922dc9699c6d47

URL: 
https://github.com/llvm/llvm-project/commit/788c7d2ec11dfc868a5b03478c922dc9699c6d47
DIFF: 
https://github.com/llvm/llvm-project/commit/788c7d2ec11dfc868a5b03478c922dc9699c6d47.diff

LOG: [clang][docs] Fix documentation of -O

D79916 changed the behaviour from -O2 to -O1 but the documentation was
not updated to reflect this.

Added: 


Modified: 
clang/docs/CommandGuide/clang.rst

Removed: 




diff  --git a/clang/docs/CommandGuide/clang.rst 
b/clang/docs/CommandGuide/clang.rst
index 11169e352894..a24e138e86a7 100644
--- a/clang/docs/CommandGuide/clang.rst
+++ b/clang/docs/CommandGuide/clang.rst
@@ -385,7 +385,7 @@ Code Generation Options
 :option:`-Og` Like :option:`-O1`. In future versions, this option might
 disable 
diff erent optimizations in order to improve debuggability.
 
-:option:`-O` Equivalent to :option:`-O2`.
+:option:`-O` Equivalent to :option:`-O1`.
 
 :option:`-O4` and higher
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 22215e4 - [Driver][NFC] Add explicit break to final case

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2021-02-23T14:17:15Z
New Revision: 22215e49233861e52158fcb0b71449ac62e1b41b

URL: 
https://github.com/llvm/llvm-project/commit/22215e49233861e52158fcb0b71449ac62e1b41b
DIFF: 
https://github.com/llvm/llvm-project/commit/22215e49233861e52158fcb0b71449ac62e1b41b.diff

LOG: [Driver][NFC] Add explicit break to final case

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 17bb48cd595d..471cefdb3fdd 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -370,6 +370,7 @@ static void getTargetFeatures(const Driver &D, const 
llvm::Triple &Triple,
 break;
   case llvm::Triple::ve:
 ve::getVETargetFeatures(D, Args, Features);
+break;
   }
 
   for (auto Feature : unifyTargetFeatures(Features)) {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 9e0d550 - [clang][NFC] Clean up whitespace in ClangOpcodesEmitter output

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2021-02-27T01:28:56Z
New Revision: 9e0d55024d4ed776f209ee04e260bdd314854993

URL: 
https://github.com/llvm/llvm-project/commit/9e0d55024d4ed776f209ee04e260bdd314854993
DIFF: 
https://github.com/llvm/llvm-project/commit/9e0d55024d4ed776f209ee04e260bdd314854993.diff

LOG: [clang][NFC] Clean up whitespace in ClangOpcodesEmitter output

This should now be about as style-conforming as TableGen'ed code ever
can reasonably be.

Added: 


Modified: 
clang/utils/TableGen/ClangOpcodesEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/ClangOpcodesEmitter.cpp 
b/clang/utils/TableGen/ClangOpcodesEmitter.cpp
index e5bfac5ba1b6f..ffeedcdf0ee27 100644
--- a/clang/utils/TableGen/ClangOpcodesEmitter.cpp
+++ b/clang/utils/TableGen/ClangOpcodesEmitter.cpp
@@ -122,13 +122,13 @@ void ClangOpcodesEmitter::EmitInterp(raw_ostream &OS, 
StringRef N, Record *R) {
 
 // Emit calls to read arguments.
 for (size_t I = 0, N = Args.size(); I < N; ++I) {
-  OS << "\tauto V" << I;
+  OS << "  auto V" << I;
   OS << " = ";
   OS << "PC.read<" << Args[I]->getValueAsString("Name") << ">();\n";
 }
 
 // Emit a call to the template method and pass arguments.
-OS << "\tif (!" << N;
+OS << "  if (!" << N;
 PrintTypes(OS, TS);
 OS << "(S";
 if (ChangesPC)
@@ -140,15 +140,15 @@ void ClangOpcodesEmitter::EmitInterp(raw_ostream &OS, 
StringRef N, Record *R) {
 for (size_t I = 0, N = Args.size(); I < N; ++I)
   OS << ", V" << I;
 OS << "))\n";
-OS << "\t\treturn false;\n";
+OS << "return false;\n";
 
 // Bail out if interpreter returned.
 if (CanReturn) {
-  OS << "\tif (!S.Current || S.Current->isRoot())\n";
-  OS << "\t\treturn true;\n";
+  OS << "  if (!S.Current || S.Current->isRoot())\n";
+  OS << "return true;\n";
 }
 
-OS << "\tcontinue;\n";
+OS << "  continue;\n";
 OS << "}\n";
   });
   OS << "#endif\n";
@@ -158,14 +158,14 @@ void ClangOpcodesEmitter::EmitDisasm(raw_ostream &OS, 
StringRef N, Record *R) {
   OS << "#ifdef GET_DISASM\n";
   Enumerate(R, N, [R, &OS](ArrayRef, const Twine &ID) {
 OS << "case OP_" << ID << ":\n";
-OS << "\tPrintName(\"" << ID << "\");\n";
-OS << "\tOS << \"\\t\"";
+OS << "  PrintName(\"" << ID << "\");\n";
+OS << "  OS << \"\\t\"";
 
 for (auto *Arg : R->getValueAsListOfDefs("Args"))
   OS << " << PC.read<" << Arg->getValueAsString("Name") << ">() << \" \"";
 
-OS << "<< \"\\n\";\n";
-OS << "\tcontinue;\n";
+OS << " << \"\\n\";\n";
+OS << "  continue;\n";
   });
   OS << "#endif\n";
 }
@@ -181,11 +181,11 @@ void ClangOpcodesEmitter::EmitEmitter(raw_ostream &OS, 
StringRef N, Record *R) {
 // Emit the list of arguments.
 OS << "bool ByteCodeEmitter::emit" << ID << "(";
 for (size_t I = 0, N = Args.size(); I < N; ++I)
-  OS << Args[I]->getValueAsString("Name") << " A" << I << ",";
+  OS << Args[I]->getValueAsString("Name") << " A" << I << ", ";
 OS << "const SourceInfo &L) {\n";
 
 // Emit a call to write the opcodes.
-OS << "\treturn emitOp<";
+OS << "  return emitOp<";
 for (size_t I = 0, N = Args.size(); I < N; ++I) {
   if (I != 0)
 OS << ", ";
@@ -250,7 +250,7 @@ void ClangOpcodesEmitter::EmitGroup(raw_ostream &OS, 
StringRef N, Record *R) {
 
   // Emit the dispatch implementation in the source.
   OS << "#if defined(GET_EVAL_IMPL) || defined(GET_LINK_IMPL)\n";
-  OS << "bool \n";
+  OS << "bool\n";
   OS << "#if defined(GET_EVAL_IMPL)\n";
   OS << "EvalEmitter\n";
   OS << "#else\n";
@@ -271,13 +271,14 @@ void ClangOpcodesEmitter::EmitGroup(raw_ostream &OS, 
StringRef N, Record *R) {
   // Custom evaluator methods dispatch to template methods.
   if (R->getValueAsBit("HasCustomEval")) {
 OS << "#ifdef GET_LINK_IMPL\n";
-OS << "return emit" << ID << "\n";
+OS << "return emit" << ID << "\n";
 OS << "#else\n";
-OS << "return emit" << N;
+OS << "return emit" << N;
 PrintTypes(OS, TS);
 OS << "\n#endif\n";
+OS << "  ";
   } else {
-OS << "return emit" << ID;
+OS << "return emit" << ID;
   }
 
   OS << "(";
@@ -290,19 +291,19 @@ void ClangOpcodesEmitter::EmitGroup(raw_ostream &OS, 
StringRef N, Record *R) {
 
 // Print a switch statement selecting T.
 if (auto *TypeClass = dyn_cast(Types->getElement(I))) {
-  OS << "switch (T" << I << "){\n";
+  OS << "  switch (T" << I << ") {\n";
   auto Cases = TypeClass->getDef()->getValueAsListOfDefs("Types");
   for (auto *Case : Cases) {
-OS << "case PT_" << Case->getName() << ":\n";
+OS << "  case PT_" << Case->getName() << ":\n";
 TS.push_back(Case);
 Rec(I + 1, ID + Case->getName());
 TS.pop_back();
   }
   // Emit a default case if not

[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] 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:

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-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] [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&update 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] [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:

Not qualified (c.f. QualType)

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

[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

[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] [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]

@@ -322,6 +327,8 @@ bool 
RISCVTargetInfo::handleTargetFeatures(std::vector &Features,
   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] [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] [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 

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 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 
+// 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 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,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] [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] [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:

> ", 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] [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] [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] [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 &CGF,
   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]

@@ -3362,6 +3362,7 @@ Address 
CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction &CGF,
   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] 3450272 - [Driver][FreeBSD] Generalise lib32 handling to support arm

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2023-07-10T01:40:58+01:00
New Revision: 3450272fc281979388bb845a9fffb59b42cc2e7e

URL: 
https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59b42cc2e7e
DIFF: 
https://github.com/llvm/llvm-project/commit/3450272fc281979388bb845a9fffb59b42cc2e7e.diff

LOG: [Driver][FreeBSD] Generalise lib32 handling to support arm

The current code maintains its own list of 32-bit architectures for
which there is a 64-bit FreeBSD architecture that supports it for lib32.
This is unnecessary (if it's not supported, the directory just won't
exist), and means that, when FreeBSD gains lib32 support for a new
architecture, you need an updated toolchain that knows about it.
Instead we can check for any 32-bit architecture and have forwards
compatibility.

This is motivated by FreeBSD adding support for building arm lib32
libraries on aarch64.

Co-authored-by: Mike Karels 

Added: 


Modified: 
clang/lib/Driver/ToolChains/FreeBSD.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/FreeBSD.cpp 
b/clang/lib/Driver/ToolChains/FreeBSD.cpp
index ac336598a78c94..84e257741702ce 100644
--- a/clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ b/clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -376,8 +376,7 @@ FreeBSD::FreeBSD(const Driver &D, const llvm::Triple 
&Triple,
 
   // When targeting 32-bit platforms, look for '/usr/lib32/crt1.o' and fall
   // back to '/usr/lib' if it doesn't exist.
-  if ((Triple.getArch() == llvm::Triple::x86 || Triple.isMIPS32() ||
-   Triple.isPPC32()) &&
+  if (Triple.isArch32Bit() &&
   D.getVFS().exists(concat(getDriver().SysRoot, "/usr/lib32/crt1.o")))
 getFilePaths().push_back(concat(getDriver().SysRoot, "/usr/lib32"));
   else



___
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]

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]

https://github.com/jrtc27 opened 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]

https://github.com/jrtc27 review_request_removed 
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]

@@ -315,12 +315,16 @@ std::string 
JSONNodeDumper::createPointerRepresentation(const void *Ptr) {
 
 llvm::json::Object JSONNodeDumper::createQualType(QualType QT, bool Desugar) {
   SplitQualType SQT = QT.split();
-  llvm::json::Object Ret{{"qualType", QualType::getAsString(SQT, 
PrintPolicy)}};
+  std::string SQTS = QualType::getAsString(SQT, PrintPolicy);
+  llvm::json::Object Ret{{"qualType", SQTS}};
 
   if (Desugar && !QT.isNull()) {
 SplitQualType DSQT = QT.getSplitDesugaredType();
-if (DSQT != SQT)
-  Ret["desugaredQualType"] = QualType::getAsString(DSQT, PrintPolicy);
+if (DSQT != SQT) {
+  std::string DSQTS = QualType::getAsString(DSQT, PrintPolicy);
+  if (DSQTS != SQTS)
+Ret["desugaredQualType"] = DSQTS;
+}

jrtc27 wrote:

What's the issue for consumer code? It already needs to handle non-sugar types. 
And it's not like the type in the JSON is a structured representation of the 
QualType, it's just a textual dump, so you'd have to go and re-parse it to do 
anything with it.

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:

> > These are an artifact of how types are structured but serve little
> > purpose, merely showing that the type is sugared in some way. For
> > example, ElaboratedType's existence means struct S gets printed as
> > 'struct S':'struct S' in the AST, which is unnecessary visual clutter.
> > Note that skipping the second print when the types have the same string
> > matches what we do for diagnostics, where the aka will be skipped.
> 
> There seems to be some words missing on the last line of the commit message / 
> description.

I don't think so? What's there is what I intended to write.

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]

@@ -677,13 +677,18 @@ void TextNodeDumper::dumpBareType(QualType T, bool 
Desugar) {
   ColorScope Color(OS, ShowColors, TypeColor);
 
   SplitQualType T_split = T.split();
-  OS << "'" << QualType::getAsString(T_split, PrintPolicy) << "'";
+  std::string T_str = QualType::getAsString(T_split, PrintPolicy);
+  OS << "'" << T_str << "'";
 
   if (Desugar && !T.isNull()) {
-// If the type is sugared, also dump a (shallow) desugared type.
+// If the type is sugared, also dump a (shallow) desugared type when
+// visibly different.

jrtc27 wrote:

What's wrong with what's there? It's grammatically correct AFAIK.

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:

> So it looks like some of these changes undo some of the change introduced by 
> @mizvekov in some tests. Maybe @zygoloid or @AaronBallman has some more input 
> here.

Do you have a pointer to such changes?

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:

> > > So it looks like some of these changes undo some of the change introduced 
> > > by @mizvekov in some tests. Maybe @zygoloid or @AaronBallman has some 
> > > more input here.
> > 
> > 
> > Do you have a pointer to such changes?
> 
> One of the commits is here: 
> [15f3cd6](https://github.com/llvm/llvm-project/commit/15f3cd6bfc670ba6106184a903eb04be059e5977)
> 
> I know he did a lot of work in this area and I am not familiar with it in 
> detail but I want to make sure interested parties are not stepping on each 
> others work.

My view is that the `'struct S':'struct S'` is just an unintended side-effect 
of adding that sugar. I'm not removing that sugar, and in cases where the 
as-written type differs from the desugared type it will still print both, it 
just doesn't print both when textually there is no difference.

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] 74f2078 - [clang] Fix emitVoidPtrVAArg for non-zero default alloca address space

[Jessica Clarke via cfe-commits]

Author: Jessica Clarke
Date: 2023-05-15T20:26:49+01:00
New Revision: 74f207883bc5fe2a7300c4b4f1ff080a107ab148

URL: 
https://github.com/llvm/llvm-project/commit/74f207883bc5fe2a7300c4b4f1ff080a107ab148
DIFF: 
https://github.com/llvm/llvm-project/commit/74f207883bc5fe2a7300c4b4f1ff080a107ab148.diff

LOG: [clang] Fix emitVoidPtrVAArg for non-zero default alloca address space

Indirect arguments are passed on the stack and so va_arg should use the
default alloca address space, not hard-code 0, for pointers to those.
The only in-tree target with a non-zero default alloca address space is
AMDGPU, but that does not support variadic arguments, so we cannot test
this upstream. However, downstream in CHERI LLVM (and Morello LLVM, a
further fork of that) we have targets that do both and so require this
change.

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D132247

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index ff4d516090ea4..9fb5d9ae75f0a 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -401,8 +401,10 @@ static Address emitVoidPtrVAArg(CodeGenFunction &CGF, 
Address VAListAddr,
 
   // Cast the address we've calculated to the right type.
   llvm::Type *DirectTy = CGF.ConvertTypeForMem(ValueTy), *ElementTy = DirectTy;
-  if (IsIndirect)
-DirectTy = DirectTy->getPointerTo(0);
+  if (IsIndirect) {
+unsigned AllocaAS = CGF.CGM.getDataLayout().getAllocaAddrSpace();
+DirectTy = DirectTy->getPointerTo(AllocaAS);
+  }
 
   Address Addr = emitVoidPtrDirectVAArg(CGF, VAListAddr, DirectTy, DirectSize,
 DirectAlign, SlotSizeAndAlign,



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits