Author: lenary
Date: Wed Jul 31 02:45:55 2019
New Revision: 367403
URL: http://llvm.org/viewvc/llvm-project?rev=367403&view=rev
Log:
[RISCV] Support 'f' Inline Assembly Constraint
Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a
Author: lenary
Date: Thu Aug 1 06:14:30 2019
New Revision: 367557
URL: http://llvm.org/viewvc/llvm-project?rev=367557&view=rev
Log:
[RISCV] Add FreeBSD targets
Reviewers: asb
Reviewed By: asb
Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste,
kito-cheng, shiva0217, rogf
Author: lenary
Date: Thu Aug 1 07:23:56 2019
New Revision: 367565
URL: http://llvm.org/viewvc/llvm-project?rev=367565&view=rev
Log:
Add support for openSUSE RISC-V triple
Reviewers: asb
Reviewed By: asb
Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD,
jrtc27, zzheng,
Author: lenary
Date: Fri Jun 21 03:03:31 2019
New Revision: 364018
URL: http://llvm.org/viewvc/llvm-project?rev=364018&view=rev
Log:
[RISC-V] Add -msave-restore and -mno-save-restore to clang driver
Summary:
The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore`
to control whet
Author: lenary
Date: Mon Jul 1 07:53:56 2019
New Revision: 364777
URL: http://llvm.org/viewvc/llvm-project?rev=364777&view=rev
Log:
[RISCV] Avoid save-restore target feature warning
Summary:
LLVM issues a warning if passed unknown target features. Neither I nor
@asb noticed this until after http
Author: lenary
Date: Mon Oct 14 07:00:13 2019
New Revision: 374774
URL: http://llvm.org/viewvc/llvm-project?rev=374774&view=rev
Log:
[RISCV] enable LTO support, pass some options to linker.
Summary:
1. enable LTO need to pass target feature and abi to LTO code generation
RISCV backend need the
lenary wrote:
The reason TargetParser exists is because Target directories are only added to
the include path if you enable that target, but some cross-project target code
needs to always be available, such as the code for Triples, even when the
relevant targets are disabled. I think these add
Author: lenary
Date: Tue Aug 27 08:41:16 2019
New Revision: 370073
URL: http://llvm.org/viewvc/llvm-project?rev=370073&view=rev
Log:
[RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64
targets with atomics
Summary: This ensures that libcalls aren't generated when the target
Author: lenary
Date: Tue Sep 3 01:47:58 2019
New Revision: 370709
URL: http://llvm.org/viewvc/llvm-project?rev=370709&view=rev
Log:
[RISCV] Correct Logic around ilp32e macros
Summary:
GCC seperates the `__riscv_float_abi_*` macros and the
`__riscv_abi_rve` macro. If the chosen abi is ilp32e, `gc
Author: lenary
Date: Mon Aug 21 09:40:35 2017
New Revision: 311347
URL: http://llvm.org/viewvc/llvm-project?rev=311347&view=rev
Log:
[clang] Fix tests for Emitting Single Inline Remark
Summary: This change depends on https://reviews.llvm.org/D36054 and should be
landed at the same time.
Reviewe
Author: Sam Elliott
Date: 2019-11-15T15:10:42Z
New Revision: e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e
URL:
https://github.com/llvm/llvm-project/commit/e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e
DIFF:
https://github.com/llvm/llvm-project/commit/e3d5ff5a0b102febcddd9d58f24f18b00d4ecb4e.diff
LOG: [
Author: Sam Elliott
Date: 2019-12-16T16:36:56Z
New Revision: ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e
URL:
https://github.com/llvm/llvm-project/commit/ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e
DIFF:
https://github.com/llvm/llvm-project/commit/ce3d1c6d61dcd96f44492516f8b613bbcadaeb8e.diff
LOG: [
@@ -855,6 +863,25 @@ __rndrrs(uint64_t *__p) {
}
#endif
+/* 11.2 Guarded Control Stack intrinsics */
+#if defined(__ARM_64BIT_STATE) && __ARM_64BIT_STATE
+static __inline__ void * __attribute__((__always_inline__, __nodebug__))
+__gcspr() {
+ return (void *)__builtin_arm_rsr6
lenary wrote:
@ArcaneNibble have you seen this RFC from Arm
https://discourse.llvm.org/t/rfc-multilib-custom-flags/81058?u=lenary which I
think would be useful for RISC-V too?
https://github.com/llvm/llvm-project/pull/98856
___
cfe-commits mailing li
https://github.com/lenary approved this pull request.
https://github.com/llvm/llvm-project/pull/107816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
What's the status of backend support for the large code model? That would
presumably be a prerequisite to landing this.
https://github.com/llvm/llvm-project/pull/107817
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
lenary wrote:
> > What's the status of backend support for the large code model? That would
> > presumably be a prerequisite to landing this.
>
> It was just merged: #70308.
I expected I was out of date, thanks for the link.
The psABI says the large code model is not compatible with PIC - thi
lenary wrote:
Reviewing on the basis this is stacked on top of #107817
https://github.com/llvm/llvm-project/pull/108131
___
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/108131
___
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.
LGTM, on the basis the preprocessor changes are in a different PR.
https://github.com/llvm/llvm-project/pull/107817
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
lenary wrote:
I've reached out to Luke to ask his/RPi's opinion (but I think he might be away
at the moment, so a reply might be slow). My preference remains
`raspberrypi-rp2350` because it matches our `-` approach taken so
far (for everything except rocket).
https://github.com/llvm/llvm-proj
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/104601
This change does two kinds of splits:
- Splits each target into a different file. Some targets are left in the same
files, such as riscv32/64 and x86/_64 as these tests and lists are very similar.
- Splits up the
https://github.com/lenary approved this pull request.
I'm happy with this as a good first step to adopting the multilib YAML.
Have you, using this patch, managed to reimplement the hardcoded multilib
behaviour? This is not a blocking question, but it might give an indication of
whether more wo
@@ -0,0 +1,382 @@
+// Use --implicit-check-not={{[a-zA-Z0-9]}} to ensure no additional CPUs are
in these lists
+
+// RUN: not %clang_cc1 -triple i386--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --check-prefix X86 --implicit-check-not={{[a-zA-Z0-9]}}
+// X86: er
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From 0e9579c91242fc63eb2cb686adc105fd248fef91 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does tw
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From 0e9579c91242fc63eb2cb686adc105fd248fef91 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does tw
lenary wrote:
I've updated this and gone with `rp2350-hazard3` as that's the prevailing
consensus.
This is stacked on #104601 because i got fed up with the invalid cpu note
tests. Otherwise it's ready to review.
https://github.com/llvm/llvm-project/pull/102452
https://github.com/lenary ready_for_review
https://github.com/llvm/llvm-project/pull/102452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
I was a reviewer on the original patch, and I can see that I let some not great
things through - claiming options that should not have been claimed, etc.
I also do think that the situation has changed since then - more platform
defaults are opting out of the sbss/sdata optimisati
https://github.com/lenary approved this pull request.
https://github.com/llvm/llvm-project/pull/83093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,9 @@
+; Test emitting version_min directives.
+
+; RUN: llc %s -filetype=asm -o - --mtriple arm64-apple-tvos9.0.0 | FileCheck
%s --check-prefix=TVOS
lenary wrote:
This is not the right directory for AArch64 tests (which apple calls `arm64` in
its tri
@@ -0,0 +1,9 @@
+; Test emitting version_min directives.
+
+; RUN: llc %s -filetype=asm -o - --mtriple arm64-apple-tvos9.0.0 | FileCheck
%s --check-prefix=TVOS
lenary wrote:
That fix makes sense to me. Thanks!
https://github.com/llvm/llvm-project/pull/94514
___
https://github.com/lenary approved this pull request.
Thanks, LGTM.
As a follow-up, can you check that the instructions generated from this builtin
do inhibit the machine outliner? Maybe all GCS-modifying functions have to
inhibit the machine outliner, I'm not 100% sure.
https://github.com/ll
https://github.com/lenary approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/96903
___
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/98267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -89,14 +89,14 @@ def FeatureCrypto : ExtensionWithMArch<"crypto", "Crypto",
"FEAT_Crypto",
"Enable cryptographic instructions", [FeatureNEON, FeatureSHA2, FeatureAES]>;
def FeatureCRC : ExtensionWithMArch<"crc", "CRC", "FEAT_CRC32",
- "Enable ARMv8 CRC-32 checksum instr
lenary wrote:
Is this check even right for MTE? FEAT_MTE uses encodings that are undefined
(rather than nop-compatible) in the base architecture, even though those
encodings are not doing tag checking until you enable at least FEAT_MTE2 - so I
cannot execute e.g. `IRG` on a base armv8.0a archi
@@ -1169,7 +1169,11 @@
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv)
ILOAD x\i, (RISCV_ISIZE * \i)(a0)
.endr
// skip a0 for now
+#if defined(__riscv_abi_rve)
lenary wrote:
I don't understand how the non-e version of this list rela
@@ -258,6 +259,13 @@ static void getARMMultilibFlags(const Driver &D,
}
}
+static void getRISCVMultilibFlags(const Driver &D, const llvm::Triple &Triple,
+ const llvm::opt::ArgList &Args,
+ Multilib::flags_lis
@@ -1169,7 +1169,11 @@
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv)
ILOAD x\i, (RISCV_ISIZE * \i)(a0)
.endr
// skip a0 for now
+#if defined(__riscv_abi_rve)
lenary wrote:
> The non-e case seems to be saving/restoring all register
@@ -1169,7 +1169,11 @@
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_riscv6jumptoEv)
ILOAD x\i, (RISCV_ISIZE * \i)(a0)
.endr
// skip a0 for now
+#if defined(__riscv_abi_rve)
lenary wrote:
> Okay, I apparently did not realize that you can explicit
https://github.com/lenary approved this pull request.
I'm happy with this from a RISC-V arch/abi point of view.
https://github.com/llvm/llvm-project/pull/98855
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -258,6 +259,13 @@ static void getARMMultilibFlags(const Driver &D,
}
}
+static void getRISCVMultilibFlags(const Driver &D, const llvm::Triple &Triple,
+ const llvm::opt::ArgList &Args,
+ Multilib::flags_lis
lenary wrote:
@ArcaneNibble your contributions now definitely meet the threshold for commit
access - please request it following the instructions in the Developer Policy:
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access (also take a
read of the rest of the policy to understan
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/101192
>From d9fc0576afc4ad2521e92166f8e4b7a56da97230 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Tue, 30 Jul 2024 07:06:05 -0700
Subject: [PATCH 1/2] [clang][docs] Update Include Options Help
This adds HelpTexts
https://github.com/lenary closed
https://github.com/llvm/llvm-project/pull/101192
___
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/102452
Luke Wren's Hazard3 is an open-source 32-bit RISC-V core. The core's source
code and docs are available on github:
https://github.com/wren6991/hazard3
The core has just hit 1.0 today, which seems to me to be a g
https://github.com/lenary converted_to_draft
https://github.com/llvm/llvm-project/pull/102452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
I am happy to be point person on maintaining this core definition in LLVM, I
communicate regularly with Luke, the core designer.
As for the core itself, it's obviously maintained by Luke, and as Alex points
out, it's just been announced to be in commercial products released by
R
lenary wrote:
I do have some worries about the definition as-is, as the core in the repo has
optional features (configurable at tape-out time). Reading the RP2350
datasheet, not all of the optional features for Hazard3 are enabled (and I'm of
the opinion that the lack of arm-like `-mcpu=++no`
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/102452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/102452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -108,6 +108,7 @@ Changes to the RISC-V Backend
fill value) rather than NOPs.
* Added Syntacore SCR4 and SCR5 CPUs: ``-mcpu=syntacore-scr4/5-rv32/64``
* ``-mcpu=sifive-p470`` was added.
+* Added Hazard3 CPU: ``-mcpu=hazard3`` (32-bit only).
lenary wrote:
D
@@ -0,0 +1,90 @@
+// Use --implicit-check-not to ensure no additional CPUs are in this list
+
+// RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+// RUN: not %clang_cc1 -triple arm64--- -tune-cp
lenary wrote:
Just closing a loop because I didn't have the info until today: the Oryon info
in this patch is correct, the core does have SSBS and CCIDX.
https://github.com/llvm/llvm-project/pull/104435
___
cfe-commits mailing list
cfe-commits@lists.l
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/104601
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH] [clang][test] Split invalid-cpu-note tests
This change does two ki
@@ -0,0 +1,90 @@
+// Use --implicit-check-not to ensure no additional CPUs are in this list
+
+// RUN: not %clang_cc1 -triple arm64--- -target-cpu not-a-cpu -fsyntax-only %s
2>&1 | FileCheck %s --implicit-check-not={{[a-zA-Z0-9]}}
+// RUN: not %clang_cc1 -triple arm64--- -tune-cp
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does tw
lenary wrote:
> Is this PR stacked on
> [b125071](https://github.com/llvm/llvm-project/commit/b125071eeb35ee4a76e126967b7c29d86a1fae56)
> (I don't see any note of that in the PR description at the moment)?
>
> Edit: I found the comment that says that!
Yeah, sorry, I only stacked it about half
lenary wrote:
Failures seem unrelated. Merging.
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary closed
https://github.com/llvm/llvm-project/pull/104601
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
The commit this was stacked on is merged, and I think we have sorted out naming
issues and pinned down the exact cpu configuration, so I think this is ready
for review and merge.
https://github.com/llvm/llvm-project/pull/102452
___
cfe-
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/102452
>From b125071eeb35ee4a76e126967b7c29d86a1fae56 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Fri, 16 Aug 2024 07:52:53 -0700
Subject: [PATCH 1/2] [clang][test] Split invalid-cpu-note tests
This change does tw
@@ -839,6 +839,14 @@ def HLV_D : HLoad_r<0b0110110, 0b0, "hlv.d">,
Sched<[]>;
def HSV_D : HStore_rr<0b0110111, "hsv.d">, Sched<[]>;
}
+let Predicates = [HasStdExtSmctrOrSsctr] in {
+def SCTRCLR : Priv<"sctrclr", 0b0001000>, Sched<[]> {
lenary wrote:
https://github.com/lenary approved this pull request.
https://github.com/llvm/llvm-project/pull/105148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/lenary closed
https://github.com/llvm/llvm-project/pull/102452
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
This is also a limitation if you use `@` as a prefix as suggested in the
discourse thread - GCC's `-print-multi-lib` prints out flags with the first
`-` replaced with an `@`, which iirc some build systems also parse (i recall
crosstool-ng, but maybe it's newlib within a crosstoo
lenary wrote:
The existing implementation lines up with the ACLE, which specifies this
colon-separated syntax:
https://github.com/ARM-software/acle/blob/main/main/acle.md#aarch64-system-register
- please send an update to that document before changing this behaviour.
https://github.com/llvm/l
@@ -166,7 +155,7 @@ static bool useFramePointerForTargetByDefault(const
llvm::opt::ArgList &Args,
static bool useLeafFramePointerForTargetByDefault(const llvm::Triple &Triple) {
if (Triple.isAArch64() || Triple.isPS() || Triple.isVE() ||
- (Triple.isAndroid() && Triple
@@ -855,6 +863,25 @@ __rndrrs(uint64_t *__p) {
}
#endif
+/* 11.2 Guarded Control Stack intrinsics */
+#if defined(__ARM_64BIT_STATE) && __ARM_64BIT_STATE
+static __inline__ void * __attribute__((__always_inline__, __nodebug__))
+__gcspr() {
+ return (void *)__builtin_arm_rsr6
https://github.com/lenary approved this pull request.
Nice catch in the test. Code still LGTM.
https://github.com/llvm/llvm-project/pull/108131
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
@@ -0,0 +1,441 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --check-globals all --include-generated-funcs --version 4
+// RUN: %clang_cc1 -triple riscv64-linux-gnu -target-feature +i -emit-llvm -o
- %s | FileCheck %s
+
+__attribute_
https://github.com/lenary approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/111653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -29,6 +29,14 @@ vint32m1_t test_vr(vint32m1_t a, vint32m1_t b) {
return ret;
}
+vint32m1_t test_vd(vint32m1_t a, vint32m1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vd
+// CHECK: %0 = tail call asm sideeffect "vadd.vv $0, $1,
$2", "=^vd,^vd,^vd"( %a, %b)
+ vint32m1_t
lenary wrote:
Yeah, I went back and looked at that issue, it's helpful to know that it was
more than just the register allocator, that it was also copy propagation, which
wasn't obvious from the comments.
The failing tests are not related, but presumably caused by the rebase, but
I'll still
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112563
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH 1/2] [RISCV] Inline Assembly: RVC constraint and N modifier
This ch
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/112561
This change implements support for the `cr` and `cf` register constraints
(which allocate a RVC GPR or RVC FPR respectively), and the `N` modifier (which
prints the raw encoding of a register rather than the nam
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/112563
I'm not sure if this fix is required, but I've written the patch anyway. This
does not cause test changes, but we haven't got tests that try to use all 32
registers in inline assembly.
Broadly, for GPRs, we mad
@@ -348,6 +349,14 @@ bool RISCVAsmPrinter::PrintAsmOperand(const MachineInstr
*MI, unsigned OpNo,
if (!MO.isReg())
OS << 'i';
return false;
+case 'N': // Print the register encoding as an integer (0-31, or 0-7 when
lenary wrote:
Ah, ye
lenary wrote:
(My approach with the test was to try to use all 32 GPRs, so have it fail when
it couldn't use x0 - doing so by marking ra, sp, gp, and tp as clobbered, and
passing 28 floats)
https://github.com/llvm/llvm-project/pull/112563
___
cfe-com
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112561
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH] [RISCV] Inline Assembly: RVC constraint and N modifier
This change
https://github.com/lenary updated
https://github.com/llvm/llvm-project/pull/112563
>From bbf0b885dc5912d4dc29abcec5fe7cee7cfd1758 Mon Sep 17 00:00:00 2001
From: Sam Elliott
Date: Wed, 16 Oct 2024 05:04:45 -0700
Subject: [PATCH 1/2] [RISCV] Inline Assembly: RVC constraint and N modifier
This ch
lenary wrote:
I spent some time trying to write a test that should fail before, but doesn't
after, but it doesn't happen - I presume because x0 is reasonably dealt with by
the allocator. This maybe suggests the patch isn't needed? I'm not sure why we
do this for GPRs then.
https://github.com/
lenary wrote:
> I'm concerned that if we make i128 legal, we will have to write custom
> splitting code for every operation. Using v2i64 probably has other problems
> conflicting with the V extension fixed vector support.
I sort-of expected that making `i128` legal would be problematic, I did
https://github.com/lenary created
https://github.com/llvm/llvm-project/pull/112983
I wanted to push up this draft, to check that I was going a reasonable
direction with this work. It's still at an early stage.
I tried just adding the double-wide VTs to the GPRPair register class, but that
cau
@@ -813,6 +815,12 @@ def MRET : Priv<"mret", 0b0011000>, Sched<[]> {
let rs1 = 0;
let rs2 = 0b00010;
}
+
+def MNRET : Priv<"mnret", 0b0111000>, Sched<[]> {
lenary wrote:
Nice, thanks!
https://github.com/llvm/llvm-project/pull/111668
__
@@ -129,6 +129,7 @@ on support follow.
``Smcdeleg`` Supported
``Smcsrind`` Supported
``Smepmp``Supported
+ ``Smrnmi``Supported
lenary wrote:
This should probably be "Assembly Support" - some of the other `*ret`
ins
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
> > The Arch64 MVT::i64x8 may be a way to work around this. We could have a
> > special pair MVT only used by inline assembly.
>
> Ok, this sounds doable - so something like `MVT::xlen_pair` is the way I'll
> lean, rather than a different type for rv32/rv64.
Turns out that MVTs
lenary wrote:
So, I've just pushed an update:
- This now adds the two new MVTs, as suggested by Craig. I'm a little concerned
if this causes a problem of using too much space in SelectionDAG tables. It's
definitely a concern.
- I'm using them from `getAsmOperandValueType`, which is the right pl
lenary wrote:
I think the first thing I might do tomorrow is some of the NFC cleanups and
commenting that is in this PR.
I'm not sure the register class renaming can happen quite yet.
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits m
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
It would be great to get more comments than just Craig, so I can be sure that
there's wider consensus that adding this is good.
https://github.com/llvm/llvm-project/pull/112561
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
@@ -813,6 +815,12 @@ def MRET : Priv<"mret", 0b0011000>, Sched<[]> {
let rs1 = 0;
let rs2 = 0b00010;
}
+
+def MNRET : Priv<"mnret", 0b0111000>, Sched<[]> {
lenary wrote:
Does this need a `Requires=[HasStdExtSmrnmi]` (And a definition of
`HasStdExtSmrnmi`)
lenary wrote:
Sorry, got the rebase slightly wrong. Will re-do it tomorrow. Tests will likely
fail in the meantime. This only really affects the branch-relaxation tests.
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe
lenary wrote:
ping?
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2224,6 +2231,17 @@ bool RISCVTargetLowering::isExtractSubvectorCheap(EVT
ResVT, EVT SrcVT,
return Index == 0 || Index == ResElts;
}
+EVT RISCVTargetLowering::getAsmOperandValueType(const DataLayout &DL, Type *Ty,
+bool All
https://github.com/lenary edited
https://github.com/llvm/llvm-project/pull/112983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
lenary wrote:
I gave up on using `splitValueIntoRegisterParts` and
`joinRegisterPartsIntoValue`, and instead added a custom legalisation of
`BITCAST` with the 2*xlen type, which matches what we do for `BuildPairF64` and
`SplitF64`. This ended up being much more "symmetrical", which was nice.
1 - 100 of 226 matches
Mail list logo
