lenary wrote:
> > Not related to this PR, but I'd like to raise the question here:
> > For configurable cores, what is the best way to specify the features?
> > `-mcpu` is meant to support the base configuration, but how can we specify
> > the additional optional extensions? Apparently, failing
@@ -190,6 +192,31 @@ insertWaveSizeFeature(StringRef GPU, const Triple &T,
StringMap &Features);
} // namespace AMDGPU
+
+struct BasicSubtargetFeatureKV {
+ const char *Key; ///< K-V key string
+ unsigned Value; ///< K-V integer value
+
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/137854
>From f156620203b61fbe48c80b4b45c451f9a6c6eed9 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Tue, 29 Apr 2025 11:10:54 -0700
Subject: [PATCH 1/3] [RISCV] Xqccmp v0.3
---
clang/test/Driver/print-supported-ext
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/144398
None
>From b9e6e8f0570bad9b9d19179bd263dc3df40f8bdf Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Mon, 16 Jun 2025 10:18:10 -0700
Subject: [PATCH] [RISCV] Update Xqci to v0.13.0
---
clang/include/clang/Basi
lenary wrote:
Nice, I can navigate that UI.
Looks like a similar thing that I fixed-forward, but this time with a different
unwind library, but clang isn't very happy with mixing unwind libraries anyway.
I think I'll leave this to @quic-garvgupt to fix, using the info from your link.
https://
lenary wrote:
Do the fuchsia builders actually produce output on a failure? We seem to just
get exit code 1, but no indication of what filecheck had problems with.
https://github.com/llvm/llvm-project/pull/121829
___
cfe-commits mailing list
cfe-commi
lenary wrote:
We probably need to file an infrastructure ticket to get to the bottom of this
issue. I've seen the same issues @mshockwave has seen.
https://github.com/llvm/llvm-project/pull/144402
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
lenary wrote:
The answer is yes, this builder does set a different unwindlib.
https://github.com/llvm/llvm-project/pull/121830
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
My plan is to modify the tests to accept that there might be unwindlib
arguments between `clang_rt.builtins.a` and `-lc`, which is where the breakage
is right now.
https://github.com/llvm/llvm-project/pull/121830
___
cfe-commits mailing
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/144582
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/144582
The openmp-offload-amdgpu-runtime-2 bot specifies default rtlib of compiler-rt,
but default unwindlib of libgcc. Change the tests to accept that there may be
`"--as-needed" "-lgcc_s" "--no-as-needed"` between `l
lenary wrote:
I'm going to land this, as I'm taking "I'm aligned with this fix" as approval
from garvit (I know he's in a different time zone, which may mean he's logged
off for the night)
https://github.com/llvm/llvm-project/pull/144582
___
cfe-comm
https://github.com/lenary closed
https://github.com/llvm/llvm-project/pull/144582
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
@kewen12 I think I can see how to fix these tests, I'm just confused because
these tests seem to end up requesting both compiler-rt and libgcc. Is that bot
configured with a different default unwindlib to normal or something?
https://github.com/llvm/llvm-project/pull/121830
_
https://github.com/lenary approved this pull request.
https://github.com/llvm/llvm-project/pull/142900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary approved this pull request.
https://github.com/llvm/llvm-project/pull/144022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
I think this feature is really tough, the arm/aarch64 backends have got too
much complexity from similar features, mostly because their cpus have all their
optional features enabled by default.
I think if you can only enable additional extensions, that proposed syntax
would prob
@@ -0,0 +1,40 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+xmipscbop -mattr=+m -verify-machineinstrs
< %s \
+; RUN: | FileCheck %s -check-prefix=RV32XMIPSPREFETCH
+; RUN: llc -mtriple=riscv64 -mattr=+xmip
https://github.com/lenary approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/145685
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
This seems to only implement the first bullet point in your commit message, and
assembler/relocation/fixup support, right? Please update the PR description.
I presume there will be follow-ups for the codegen/load-store support, plus
subtarget info.
https://github.com/llvm/llvm
@@ -790,6 +790,9 @@ static constexpr DecoderListEntry DecoderList32[]{
{DecoderTableXmipscmov32,
{RISCV::FeatureVendorXMIPSCMov},
"MIPS mips.ccmov"},
+{DecoderTableXmipscbop32,
+ {RISCV::FeatureVendorXMIPSCBOP},
+ "MIPS mips.pref"},
le
lenary wrote:
What is your intention here around the LLVM 21 release cycle, knowing this is a
big feature and we are 1 week from the branch date
https://github.com/llvm/llvm-project/pull/146534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
@@ -599,11 +599,18 @@ void baremetal::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
const Driver &D = getToolChain().getDriver();
const llvm::Triple::ArchType Arch = TC.getArch();
const llvm::Triple &Triple = getToolChain().getEffectiveTriple();
+ const bool
lenary wrote:
This needs a proposal against the specification here:
https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#__attribute__interrupt-__attribute__interruptsupervisor-__attribute__interruptmachine
https://github.com/llvm/llvm-project/pull/148134
__
https://github.com/lenary commented:
The implementation here is good, and can be landed once there's a PR against
the riscv-c-api with some consensus. I don't think the chosen name will be
controversial.
https://github.com/llvm/llvm-project/pull/148134
_
301 - 325 of 325 matches
Mail list logo