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

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

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

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

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

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

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

@@ -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"); -

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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)

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

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

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

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

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)

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)

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)

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 ___

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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)

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)

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

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

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

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

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

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

@@ -234,7 +235,7 @@ Supported .. _riscv-profiles-extensions-note: -``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, ``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, ``Shvstvala``, ``Shvstvecd``, ``Ssccptr``,

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

@@ -234,7 +235,7 @@ Supported .. _riscv-profiles-extensions-note: -``Za128rs``, ``Za64rs``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, ``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, ``Shvstvala``, ``Shvstvecd``, ``Ssccptr``,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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

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

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

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.

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

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

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

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)

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

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

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)

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

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

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

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

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

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

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

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

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 >

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

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

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

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)

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

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

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

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

@@ -3362,6 +3362,7 @@ Address CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction , break; case OMPAllocateDeclAttr::OMPLargeCapMemAlloc: case OMPAllocateDeclAttr::OMPCGroupMemAlloc: + AS =

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

@@ -3362,6 +3362,7 @@ Address CGOpenMPRuntimeGPU::getAddressOfLocalVariable(CodeGenFunction , break; case OMPAllocateDeclAttr::OMPLargeCapMemAlloc: case OMPAllocateDeclAttr::OMPCGroupMemAlloc: + AS =

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

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

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

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

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

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

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

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)

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

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

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

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

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)

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

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

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)

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

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

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)

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

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

@@ -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");

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

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)

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

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

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

  1   2   >