Applied to master. Thanks!
--Philipp.
On Fri, 29 Sept 2023 at 12:34, Richard Sandiford
wrote:
>
> Manos Anagnostakis writes:
> > Improves on: 834fc2bf
> >
> > This improves the code structure of the ldp-stp policies
> > patch introduced in 834fc2bf
> >
> > Bootstrapped and regtested on aarch64-l
Assuming a fully pipelined vector unit (and from experience on
AArch64), an u-arch's scalar-to-vector move cost is likely to play a
significant role in whether this will be profitable or not.
--Philipp.
On Wed, 31 May 2023 at 00:10, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/30/23 16:01, 钟居哲 w
On Thu, 1 Jun 2023 at 18:49, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote:
> > I plan to implement BF16 vector in GCC but still waiting for ISA
> > ratified since GCC policy doesn't allow un-ratified ISA.
> Right. So those specs need to move along further be
On Thu 8. Jun 2023 at 09:35, Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> > diff --git a/gcc/config/riscv/riscv-cores.def
> b/gcc/config/riscv/riscv-cores.def
> > index 7d87ab7ce28..4078439e562 100644
> > --- a/gcc/config/riscv/riscv-cores.def
> > +++ b/gcc/config/riscv/riscv-cor
mcpu for temporary before binutils support, otherwise it just a broken
> > support for that CPU on trunk gcc.
> I pushed the binutils bits into the repo a couple months ago:
>
> > commit 1656d3f8ef56a16745689c03269412988ebcaa54
> > Author: Philipp Tomsich
> >
Rebased, retested, and applied to trunk. Thanks!
--Philipp.
On Thu, 8 Jun 2023 at 00:18, Jeff Law wrote:
>
>
>
> On 5/25/23 06:35, Manolis Tsamis wrote:
> > Propagation of the stack pointer in cprop_hardreg is currenty forbidden
> > in all cases, due to maybe_mode_change returning NULL. Relax t
Looks like I missed the OK on this one.
I can pick it up today, unless you Kito already has it in flight?
Thanks,
Philipp.
On Tue, 11 Jul 2023 at 17:51, Kito Cheng wrote:
> Hi Christoph:
>
> Ooops, I thought Philipp will push those patches, does here any other
> patches got approved but not com
Awesome, thanks!
On Wed, 12 Jul 2023 at 09:18, Kito Cheng wrote:
> Yeah, I've applied patches on my local tree and running the testsuite.
>
> On Wed, Jul 12, 2023 at 3:11 PM Philipp Tomsich
> wrote:
> >
> > Looks like I missed the OK on this one.
> > I ca
On Wed, 12 Jul 2023 at 16:05, Jeff Law wrote:
>
>
> On 7/12/23 06:48, Christoph Müllner wrote:
> > On Wed, Jul 12, 2023 at 4:05 AM Jeff Law wrote:
> >>
> >>
> >>
> >> On 7/10/23 22:44, Christoph Muellner wrote:
> >>> From: Christoph Müllner
> >>>
> >>> Recently, two identical XTheadCondMov test
Thanks, applied to trunk!
Philipp.
On Wed, 12 Jul 2023 at 16:08, Jeff Law wrote:
>
>
> On 7/12/23 08:07, Philipp Tomsich wrote:
> >
> >
> > On Wed, 12 Jul 2023 at 16:05, Jeff Law > <mailto:jeffreya...@gmail.com>> wrote:
> >
> >
&g
On Fri, 21 Jul 2023 at 19:56, Vineet Gupta wrote:
>
> DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize
> it.
>
> void zd(double *) { *d = 0.0; }
>
> currently:
>
> | fmv.d.x fa5,zero
> | fsd fa5,0(a0)
> | ret
>
> With patch
>
> | sd zero,0(a0)
> | ret
> This ca
+Manolis Tsamis
On Tue, 1 Aug 2023 at 23:56, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/1/23 13:14, Vineet Gupta wrote:
>
> >
> > I have some numbers for f-m-o v3 vs this. Attached here (vs. inline to
> > avoid the Thunderbird mangling the test formatting)
> Thanks. Of particular importance is
Very helpful! Looks as if regprop for stack_pointer is now either too
conservative — or one of our patches is missing in everyone's test
setup; we'll take a closer look.
On Wed, 2 Aug 2023 at 01:03, Vineet Gupta wrote:
>
>
>
> On 8/1/23 15:07, Philipp Tomsich wrot
Applied to master, thanks!
--Philipp.
On Mon, 7 Aug 2023 at 19:20, Jeff Law wrote:
>
>
>
> On 8/7/23 05:31, Manolis Tsamis wrote:
> > The stack pointer propagation fix 736f8fd3 turned out to be more restrictive
> > than needed by rejecting propagation of the stack pointer when REG_POINTER
> > di
On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/9/23 16:39, Tsukasa OI wrote:
> > On 2023/08/10 5:05, Jeff Law wrote:
>
> >> I'd tend to think we do not want to expose the intrinsic unless the
> >> right extensions are enabled -- even though the encoding is a no-op and
>
On Wed, 16 Aug 2023 at 03:27, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/9/23 20:25, Tsukasa OI wrote:
> > From: Tsukasa OI
> >
> > The "pause" RISC-V hint instruction requires the 'Zihintpause' extension
> > (in the assembler). However, GCC emits "pause" unconditionally, making
> > an assembl
On Wed, 16 Aug 2023 at 21:10, Alexander Monakov wrote:
>
>
> On Tue, 15 Aug 2023, Jeff Law wrote:
>
> > Because if the compiler can optimize it automatically, then the projects
> > have
> > to do literally nothing to take advantage of it. They just compile normally
> > and their bitwise CRC gets
This should be covered by PR110308 (proposed fix attached there) and PR110313.
Our bootstrap runs are still in progress to confirm.
On Thu, 22 Jun 2023 at 09:40, Richard Biener wrote:
>
> On Thu, Jun 22, 2023 at 1:42 AM Thiago Jung Bauermann
> wrote:
> >
> >
> > Hello,
> >
> > Jeff Law writes:
.
(find_oldest_value_reg): Special handling of stack_pointer_rtx.
(copyprop_hardreg_forward_1): Ditto.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr110308.C: New test.
Signed-off-by: Manolis Tsamis
Signed-off-by: Philipp Tomsich
---
This addresses both the PRs (110308 and
Richard,
OK for backport to GCC-13?
Thanks,
Philipp.
On Thu, 22 Jun 2023 at 16:18, Richard Sandiford via Gcc-patches
wrote:
>
> Di Zhao OS via Gcc-patches writes:
> > This patch enables reassociation of floating-point additions on ampere1.
> > This brings about 1% overall benefit on spec2017 f
mode.
(maybe_copy_reg_attrs): New function.
(find_oldest_value_reg): Use maybe_copy_reg_attrs.
(copyprop_hardreg_forward_1): Ditto.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr110308.C: New test.
Signed-off-by: Manolis Tsamis
Signed-off-by: Philipp Tomsich
/22/23 05:11, Philipp Tomsich wrote:
> > From: Manolis Tsamis
> >
> > Fixes: 6a2e8dcbbd4bab3
> >
> > Propagation for the stack pointer in regcprop was enabled in
> > 6a2e8dcbbd4bab3, but set ORIGINAL_REGNO/REG_ATTRS/REG_POINTER for
> > stack_pointer_r
Thanks, applied to master.
--Philipp.
On Mon, 3 Jul 2023 at 15:42, Kito Cheng wrote:
> Thanks, LGTM :)
>
> Christoph Muellner 於 2023年7月3日 週一，19:08寫道：
>
>> From: Christoph Müllner
>>
>> This series adds basic support for the vector crypto extensions:
>> * Zvbb
>> * Zvbc
>> * Zvkg
>> * Zvkned
>>
On Fri, 7 Jul 2023 at 10:28, Di Zhao OS via Gcc-patches
wrote:
>
> Update the patch so it can apply.
>
> Tested on spec2017 fprate cases again. With option "-funroll-loops -Ofast
> -flto",
> the improvements of 1-copy run are:
>
> Ampere1:
> 508.namd_r 4.26%
> 510.parest_r2.55%
>
Jakub,
it looks like you did a lot of work on reassoc in the past — could you
have a quick look and comment?
Thanks,
Philipp.
On Tue, 11 Jul 2023 at 04:59, Di Zhao OS wrote:
>
> Attached is an updated version of the patch.
>
> Based on Philipp's review, some changes:
>
> 1. Defined new enum fm
On Tue, 28 Feb 2023 at 06:00, Lin Sinan wrote:
>
> From: Lin Sinan
>
> The partial subreg check should be for subreg operand(operand 1) instead of
> the immediate operand(operand 2). This change also fix pr68648.c in zbs.
Good catch.
Reviewed-by:
>
> gcc/Changelog:
>
> * config/riscv/riscv.cc (riscv_rtx_costs): Fixed IN_RANGE() to
> use exact_log2().
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zba-shNadd-07.c: f2(i*783) now generates MUL vs.
> 5 insn sh1add+slli+add+slli+sub.
> * gcc.target/riscv/pr108987.c: New test.
>
> Signed-off-by: Vineet Gupta
Reviewed-by: Philipp Tomsich
On Sun, 5 Mar 2023 at 11:19, Kito Cheng wrote:
> LGTM :)
>
Applied to master, thanks!
--Philipp.
On Thu, Mar 2, 2023 at 4:36 PM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > This series introduces support for the T-Head specific RISC-V ISA
> extensions
> > which are avai
Applied to master, thanks!
Philipp.
On Sun, 5 Mar 2023 at 11:18, Kito Cheng wrote:
> LGTM :)
>
>
> On Fri, Feb 24, 2023 at 7:19 PM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > This patch documents the new T-Head CPU support for RISC-V.
> >
> > Signed-off-by: Christoph Mü
Bootstrapped and reg-tested overnight for x86 and aarch64.
Applied to master, thanks!
Philipp.
On Tue, 9 May 2023 at 09:13, Richard Biener wrote:
>
> On Tue, Dec 20, 2022 at 1:23 PM Manolis Tsamis
> wrote:
> >
> > When using SWAR (SIMD in a register) techniques a comparison operation
> > with
On Mon, 15 May 2023 at 10:18, wrote:
>
> From: Juzhe-Zhong
>
> Since we are going to have fixed-point intrinsics that are modeling rounding
> mode
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
>
> We should have operand to specify rounding mode in fixed-point instructions.
> We d
On Thu, 25 May 2023 at 16:14, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/25/23 07:50, Richard Biener wrote:
> > On Thu, May 25, 2023 at 3:32 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 5/25/23 07:01, Richard Biener via Gcc-patches wrote:
> >>> On Thu, May 25, 2023 at 2:36 PM M
LGTM. Happy to move this forward, once it receives an OK from one of you.
--Philipp.
On Fri, 26 May 2023 at 02:53, Die Li wrote:
>
> This patch allows less instructions to be used when TARGET_XTHEADCONDMOV is
> enabled.
>
> Provide an example from the existing testcases.
>
> Testcase:
> int Co
g:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Update
Ampere-1 core entry.
Signed-off-by: Philipp Tomsich
---
Ok for backport?
gcc/config/aarch64/aarch64-cores.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64-cores.def
river-aarch64.cc (readline): Fix off-by-one.
Signed-off-by: Philipp Tomsich
---
gcc/config/aarch64/driver-aarch64.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/aarch64/driver-aarch64.cc
b/gcc/config/aarch64/driver-aarch64.cc
index 52ff537908e..48250e
On Tue, 4 Oct 2022 at 18:43, Richard Sandiford
wrote:
>
> Philipp Tomsich writes:
> > This brings the extensions detected by -mcpu=native on Ampere-1 systems
> > in sync with the defaults generated for -mcpu=ampere1.
> >
> > Note that some kernel versions may misre
river-aarch64.cc (readline): Fix off-by-one.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cpunative/info_18: New test.
* gcc.target/aarch64/cpunative/native_cpu_18.c: New test.
Signed-off-by: Philipp Tomsich
---
Changes in v2:
- Add a a regression test (as per review comment).
27;).
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Update
Ampere-1 core entry.
Signed-off-by: Philipp Tomsich
---
Ok for backport?
Changes in v2:
- Removed explicit RCPC, as the feature is now implicitly included
in the 8.3 feature definition.
gcc/co
On Thu, 6 Oct 2022 at 12:06, Richard Sandiford
wrote:
> Philipp Tomsich writes:
> > Fixes: 341573406b39
> >
> > Don't subtract one from the result of strnlen() when trying to point
> > to the first character after the current string. This issue would
> >
Applied to master. Thanks!
Philipp.
On Thu, 6 Oct 2022 at 12:07, Richard Sandiford
wrote:
> Philipp Tomsich writes:
> > This brings the extensions detected by -mcpu=native on Ampere-1 systems
> > in sync with the defaults generated for -mcpu=ampere1.
> >
> >
On Fri, Mar 18, 2022 at 7:58 AM Kito Cheng wrote:
> I would suggest rename those __builtin_riscv_* to
> __builtin_riscv_cmo_*, that's less confusing, __builtin_riscv_zero
> just seems like it will return a zero value.
>
You meant cbo_zero, right?
CMO was only the task-group name, but the extens
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta wrote:
>
> This is at par with other major arches such as aarch64, i386, s390 ...
>
> No testsuite regressions: same numbers w/ w/o
Putting that check seems a good idea, but I haven't seen any cases
related to this get through anyway.
Do you have
nks for the patch, I like this approach, that can easily configure
> > different capabilities for each core :)
> >
> > So there are only a few minor comments for this patch.
> >
> > On Mon, Nov 15, 2021 at 5:49 AM Philipp Tomsich
> > wrote:
> >>
> &g
On Wed, 2 Nov 2022 at 15:21, Christoph Müllner
wrote:
>
>
>
> On Thu, Oct 27, 2022 at 10:51 PM Palmer Dabbelt wrote:
>>
>> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu wrote:
>> > On Thu, Oct 27, 2022 at 8:11 PM Christoph Muellner <
>> > christoph.muell...@vrull.eu> wrote
Applied to gcc-wwwdocs/master. Thanks!
Philipp.
On Wed, 2 Nov 2022 at 17:12, Kito Cheng wrote:
>
> LGTM, thanks!
>
> On Wed, Nov 2, 2022 at 7:59 AM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > This patch documents the new RISC-V Zawrs support.
> >
> > Signed-off-by: Chris
Applied to master (with a fixed-up commit message), thanks!
Note that the Zawrs has been approved for ratification by the RISC-V
BoD on Oct 20th.
--Philipp.
On Thu, 27 Oct 2022 at 22:51, Palmer Dabbelt wrote:
>
> On Thu, 27 Oct 2022 11:23:17 PDT (-0700), christoph.muell...@vrull.eu wrote:
> > O
On Wed, 2 Nov 2022 at 23:06, Palmer Dabbelt wrote:
>
> On Wed, 02 Nov 2022 05:52:34 PDT (-0700), jia...@iscas.ac.cn wrote:
> > This patch just add name support contain in profiles.
> > Set the extension version as 0.1.
>
> Or maybe v0.8, as they're in the v0.8 profile spec? I doubt it really
> ma
:
* gcc.target/riscv/shift-shift-2.c: Adjust.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/riscv.cc | 15 +++
gcc/testsuite/gcc.target/riscv/shift-shift-2.c | 2 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc
.
(CTZ_DEFINED_VALUE_AT_ZERO): Same.
gcc/testsuite/ChangeLog:
* gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
when compiling for riscv64.
* gcc.target/riscv/zbb-ctz.c: New test.
Signed-off-by: Philipp Tomsich
Signed-off-by: Manolis Tsamis
Co-developed-by: Manolis
Kito,
Did you have a chance to take a look at this one?
I assume this will have to wait until we reopen for 13...
OK for 13? Also: OK for a backport (once a branch for that exists)?
Philipp.
On Sun, 24 Apr 2022 at 01:44, Philipp Tomsich wrote:
>
> The Zbb support has introduced ctz a
.
* lib/target-supports.exp: Recognize RV32 or RV64 via XLEN
Signed-off-by: Philipp Tomsich
Signed-off-by: Manolis Tsamis
Co-developed-by: Manolis Tsamis
---
Changes in v2:
- Address review comments
- Merge the different target-specific testcases for CLZ into one
- Add RV32 tests
- Fix
documentation for RISC-V specific
> > test target keywords
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
> > when compiling for riscv64 and subsume gcc.target/aarch64/pr90838.c
> >
On Fri, 13 May 2022 at 12:00, Christoph Müllner wrote:
>
> On Wed, May 11, 2022 at 2:02 AM Palmer Dabbelt wrote:
> >
> > [Sorry for cross-posting to a bunch of lists, I figured it'd be best to
> > have all the discussions in one thread.]
> >
> > We currently only support what is defined by offici
On Fri, 13 May 2022 at 12:58, Florian Weimer wrote:
>
> * Christoph Müllner via Binutils:
>
> > I'd like to add two points to this topic and raise two questions.
> >
> > 1) Accepting vendor extensions = avoidance of fragmentation
> >
> > RISC-V implementors are actively encouraged to implement the
.
* lib/target-supports.exp: Recognize RV32 or RV64 via XLEN
Signed-off-by: Philipp Tomsich
Signed-off-by: Manolis Tsamis
Co-developed-by: Manolis Tsamis
---
Changes in v3:
- Address nit from Kito (use rv64 and rv32 on gcc.dg/pr90838.c
consistently.
Changes in v2:
- Address review
Added the two nits from Kito's review and … Applied to trunk!
On Fri, 13 May 2022 at 22:16, Philipp Tomsich wrote:
>
> The Zbb support has introduced ctz and clz to the backend, but some
> transformations in GCC need to know what the value of c[lt]z at zero
> is. This affects
A generous [snip], as this has been getting a bit long.
On Sun, 15 May 2022 at 03:21, Palmer Dabbelt wrote:
> I am worried about bad
> actors leveraging any policy to make a bunch of noise, as that's a
> pretty persistent problem in RISC-V land and it looks like things are
> going to get worse b
Good catch!
On Mon, 23 May 2022 at 20:12, Vineet Gupta wrote:
> Under extreme register pressure, compiler can use FP <--> int
> moves as a cheap alternate to spilling to memory.
> This was seen with SPEC2017 FP benchmark 507.cactu:
> ML_BSSN_Advect.cc:ML_BSSN_Advect_Body()
>
> | fmv.d.x fa
Code-generation currently misses some opportunities for optimized
sequences when zero-extension is combined with shifts.
Philipp Tomsich (3):
RISC-V: add consecutive_bits_operand predicate
RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w
RISC-V: Replace
Provide an easy way to constrain for constants that are a a single,
consecutive run of ones.
gcc/ChangeLog:
* config/riscv/predicates.md (consecutive_bits_operand):
Implement new predicate.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/predicates.md | 11
a splitter handling these cases.
gcc/ChangeLog:
* config/riscv/bitmanip.md: Add split to handle opportunities
for slli + sh[123]add.uw
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zba-shadd.c: New test.
Signed-off-by: Philipp Tomsich
Co-developed-by: Manolis Tsami
:
f:
sllia0,a0,33
srlia0,a0,28
add a0,a0,a1
ret
gcc/ChangeLog:
* config/riscv/riscv.md (zero_extendsidi2_shifted): Replace
with a generalized split that requires no clobber, runs
before reload and works for smaller masks.
Si
a0,a0
neg a0,a0
ret
Following this change, it results in:
bexti a0,a0,4
addia0,a0,-1
ret
Signed-off-by: Philipp Tomsich
gcc/ChangeLog:
* config/riscv/bitmanip.md: Add a splitter to generate
polarity-reversed masks from a set bit usin
/riscv/zbs-bexti.c: Add testcases.
Signed-off-by: Philipp Tomsich
Co-developed-by: Manolis Tsamis
---
gcc/config/riscv/bitmanip.md | 12 +++
gcc/testsuite/gcc.target/riscv/zbs-bext.c | 23 +++---
gcc/testsuite/gcc.target/riscv/zbs-bexti.c | 23 +++
, then invert bit'.
This change improves the previously generated
srl a0,a0,a1
not a0,a0
andi a0,a0,1
into
bext a0,a0,a1
xori a0,a0,1
Signed-off-by: Philipp Tomsich
gcc/ChangeLog:
* config/riscv/bitmanip.md: Add split covering
"(a & (1 << B
ing on 0x8000
in SImode.
* gcc/config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): Allow for
any single-bit value, moving the special case for 0x8000 to
riscv_build_integer_1 (in riscv.c).
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/riscv.c
From: Philipp Tomsich
The function
long f(long a)
{
return(a & 0xull) << 3;
}
is folded into
_1 = a_2(D) << 3;
_3 = _1 & 34359738360;
wheras the construction
return (a & 0xull) * 8;
results in
_1 = a_2(D) & 429496
From: Philipp Tomsich
csmith managed to sneak a shift wider than the bit-width of a register
past the frontend (found when addressing a bug in our bitmanip machine
description): no warning is given and an unneeded shift is generated.
This behaviour was validated for the resulting assembly both
On Wed, 11 Nov 2020 at 19:17, Jeff Law wrote:
>
>
> On 11/11/20 3:55 AM, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, Nov 11, 2020 at 11:43:34AM +0100, Philipp Tomsich wrote:
> >> The patch addresses this by disallowing that rule, if an exact power-of-2
> >>
On Wed, 11 Nov 2020 at 20:59, Jakub Jelinek wrote:
> >
> > The simplification that distributes the shift (i.e. the one that Jakub
> > referred
> > to as fighting the new rule) is also run after GIMPLE has been expanded to
> > RTX. In my understanding, this still implies that even if we have a
>
From: Philipp Tomsich
While most shifts wider than the bitwidth of a type will be caught by
other passes, it is possible that these show up for VRP.
Consider the following example:
int func (int a, int b, int c)
{
return (a << ((b && c) - 1));
}
This adds simplif
From: Philipp Tomsich
In case a negative shift operand makes it through into the backend,
it will be treated as unsigned and truncated (using a mask) to fit
into the range 0..31 (for SImode) and 0..63 (for DImode).
Consider the following output illustrating the issue and shows how
the shift
Jim,
On Mon, 16 Nov 2020 at 23:28, Jim Wilson wrote:
>
> On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
wrote:
>>
>> In case a negative shift operand makes it through into the backend,
>> it will be treated as unsigned and truncated (using a mask) to fit
>> in
On Mon, 16 Nov 2020 at 23:38, Jim Wilson wrote:
> On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich
> wrote:
>
>> This adds simplify_using_ranges::simplify_lshift_using_ranges to
>> detect and rewrite such cases. If the intersection of meaningful
>> shift amounts for
This adds support and a basic turning model for the Ampere Computing
"Ampere-1" CPU.
The Ampere-1 implements the ARMv8.6 architecture in A64 mode and is
modelled as a 4-wide issue (as with all modern micro-architectures,
the chosen issue rate is a compromise between the maximum dispatch
rate and t
Richard,
On Wed, 3 Nov 2021 at 10:08, Richard Sandiford
wrote:
>
> Philipp Tomsich writes:
> > This adds support and a basic tuning model for the Ampere Computing
> > "Ampere-1" CPU.
> >
> > The Ampere-1 implements the ARMv8.6 architecture in A64 mode a
a srli is emitted otherwise...
gcc/ChangeLog:
* optabs.c (expand_unop): support expanding a HImode bswap
using SImode or DImode, followed by a shift.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbb-bswap.c: New test.
Signed-off-by: Philipp Tomsich
---
gc
ppress redundant extensions
Philipp Tomsich (8):
bswap: synthesize HImode bswap from SImode or DImode
RISC-V: costs: handle BSWAP
RISC-V: costs: support shift-and-add in strength-reduction
RISC-V: bitmanip: fix constant-loading for (1ULL << 31) in DImode
RISC-V: bitmanip: improvemen
The BSWAP operation is not handled in rtx_costs. Add it.
gcc/ChangeLog:
* config/riscv/riscv.c (rtx_costs): Add BSWAP.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/riscv.c | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv
hesized as:
sh2add a0,a0,a0 // *5 = a + 4 * a
sh2add a0,a0,a0 // *5 = a + 4 * a
sllia0,a0,3// *8
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_rtx_costs): Recognize shNadd,
if expressed as a plus and multiplication with a power-of-2.
Signed-off-by: Phili
ing on 0x8000
in SImode.
* gcc/config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): Allow for
any single-bit value, moving the special case for 0x8000 to
riscv_build_integer_1 (in riscv.c).
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/riscv.c | 9
cc/ChangeLog:
* config/riscv/bitmanip.md (rotlsi3, rotldi3, rotlsi3_sext):
Synthesize rotate-left-by-immediate from a rotate-right insn.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/bitmanip.md | 39 ++--
1 file changed, 33 insertions(+), 6 deleti
addi.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbs-bexti.c: New test.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/bitmanip.md | 13 +
gcc/testsuite/gcc.target/riscv/zbs-bexti.c | 14 ++
2 files changed, 27 insertions(+)
create mode 100644 gcc/testsuit
.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/bitmanip.md | 8
gcc/config/riscv/riscv.md| 3 +++
2 files changed, 11 insertions(+)
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 9e10280e306..000deb48b16 100644
--- a/gcc/config/riscv/bitmanip.md
redundant sign- or zero-extensions
are emitted.
Signed-off-by: Philipp Tomsich
---
gcc/config/riscv/bitmanip.md | 14 +++---
gcc/testsuite/gcc.target/riscv/zbb-min-max.c | 20 +---
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a
,a0,a1
> ret
>
> ----------
> v64gc_zba_zbb -O3 w/ this patch:
> foo6:
> max a0,a0,a1
> ret
>
> On Thu, Nov 11, 2021 at 10:10 PM Philipp Tomsich
> wrote:
> >
> > While min/minu/max/maxu instr
:
> >
> > IIRC it's not work even without sign extend pattern since I did similar
> > experimental before (not for RISC-V, but same concept), I guess I need more
> > time to test that.
> >
> > Philipp Tomsich 於 2021年11月12日 週五 00:18 寫道：
> >>
> &g
patterns supported by VT1.
Philipp Tomsich (2):
RISC-V: Add basic support for the Ventana-VT1 core
RISC-V: Add instruction fusion (for ventana-vt1)
gcc/config/riscv/riscv-cores.def | 2 +
gcc/config/riscv/riscv-opts.h| 3 +-
gcc/config/riscv/riscv.c | 210
From: Philipp Tomsich
The Ventana-VT1 core is compatible with rv64gc and Zb[abcs].
This introduces a placeholder -mcpu=ventana-vt1, so tooling and
scripts don't need to change once full support (pipeline, tuning,
etc.) will become public later.
gcc/ChangeLog:
* config/riscv/
From: Philipp Tomsich
The Ventana VT1 core supports quad-issue and instruction fusion.
This implemented TARGET_SCHED_MACRO_FUSION_P to keep fusible sequences
together and adds idiom matcheing for the supported fusion cases.
gcc/ChangeLog:
* config/riscv/riscv.c (enum riscv_fusion_pairs
This adds support and a basic turning model for the Ampere Computing
"Ampere-1" CPU.
The Ampere-1 implements the ARMv8.6 architecture in A64 mode and is
modelled as a 4-wide issue (as with all modern micro-architectures,
the chosen issue rate is a compromise between the maximum dispatch
rate and t
Jeff,
just a heads-up that that trunk (i.e., the soon-to-be GCC14) still
generates the suboptimal sequence:
https://godbolt.org/z/K9YYEPsvY
Thanks,
Philipp.
On Mon, 21 Nov 2022 at 18:00, Philipp Tomsich wrote:
>
> On Sun, 20 Nov 2022 at 17:38, Jeff Law wrote:
> >
> >
&g
On Sat 6. Apr 2024 at 06:52, Jeff Law wrote:
>
>
> On 3/27/24 4:55 AM, Philipp Tomsich wrote:
> > Jeff,
> >
> > just a heads-up that that trunk (i.e., the soon-to-be GCC14) still
> > generates the suboptimal sequence:
> >https://godbolt.org/z/K9YYEPs
Applied to master, thanks!
--Philipp.
On Wed, 24 Jan 2024 at 12:43, Richard Sandiford
wrote:
> Manos Anagnostakis writes:
> > The current ldp/stp policy framework implementation was missing cases,
> where
> > the memory operands were reversed. Therefore the call to the framework
> function
> >
* config/aarch64/aarch64-store-forwarding.cc: New file.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/ldp_ssll_no_overlap_address.c: New test.
> > * gcc.target/aarch64/ldp_ssll_no_overlap_offset.c: New test.
> >
On Mon, 19 Dec 2022 at 05:20, Kito Cheng wrote:
>
> LGTM with a nit:
>
> ...
> > + "TARGET_XTHEADBA
> > + && (INTVAL (operands[2]) >= 0) && (INTVAL (operands[2]) <= 3)"
>
> IN_RANGE(INTVAL(operands[2]), 0, 3)
>
> and I am little bit suppress it can be zero
So was I, when reading the specificat
On Tue, 27 Dec 2022 at 19:58, Palmer Dabbelt wrote:
>
> On Tue, 27 Dec 2022 09:35:55 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> >
> >
> > On 12/21/22 11:31, Christoph Muellner wrote:
> >> From: Christoph Müllner
> >>
> >> This series adds basic support for the vector crypto extensions:
> >> *
Applied to master, thanks!
Philipp.
On Mon, 19 Dec 2022 at 03:49, Kito Cheng wrote:
> LGTM, you can commit this separately if you want :)
>
> On Mon, Dec 19, 2022 at 9:09 AM Christoph Muellner
> wrote:
> >
> > From: Christoph Müllner
> >
> > The comment above the enumeration of existing attri
Applied to master (with the change from the reviews), thanks!
Philipp.
On Mon, 19 Dec 2022 at 07:30, Kito Cheng wrote:
> just one more nit: Use INVALID_REGNUM as sentinel value for
> riscv_next_saved_reg, otherwise LGTM, and feel free to commit that
> separately :)
>
> On Mon, Dec 19, 2022 at 9
On Wed, 28 Dec 2022 at 19:18, Raphael Moreira Zinsly <
rzin...@ventanamicro.com> wrote:
> The Zbb min/max pattern was not matching 32-bit sources when
> compiling for 64-bit.
> This patch separates the pattern into SImode and DImode, and
> use a define_expand to handle SImode on 64-bit.
> zbb-min-
1 - 100 of 364 matches
Mail list logo
