> That "supposed to" is only *one* possible implementation.
> The one in CRIS - and I believe the preferred one; one I
> should advocate more - is to *always* expose clobbering of
> the flags.
Yes, both approaches are acceptable IMO and should work.
--
Eric Botcazou
Jeff Law via Gcc-patches writes:
> On 4/18/23 07:02, Richard Sandiford via Gcc-patches wrote:
>> "Victor L. Do Nascimento" writes:
>>> The function `constrain_operands' lacked the logic to consider relaxed
>>> memory constraints when "traditional" memory constraints were not
>>> satisfied, creati
On Tue, 18 Apr 2023 at 16:59, Jonathan Wakely via Libstdc++
wrote:
> diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> b/libstdc++-v3/config/abi/pre/gnu.ver
> index 4ae63094eb7..7c015524b62 100644
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2512,
> >
> > I do not think LTO is of any help here. You can allways call non-LTO
> > const function from outer-world and that function can will end up
> > calling back to instrumented const function in your unit which
> > effectively makes the extenral const function non-const.
>
> Hmm, true.
>
> >
IPA currently puts *some* irange's in GC memory. When I contribute
support for generic ranges in IPA, we'll need to change this to
vrange. This patch adds GTY support for both vrange and frange.
gcc/ChangeLog:
* value-range.cc (gt_ggc_mx): New.
(gt_pch_nx): New.
* value-
Hi All,
This patch adds support for a compact syntax for specifying constraints in
instruction patterns. Credit for the idea goes to Richard Earnshaw.
I am sending up this RFC to get feedback for it's inclusion in GCC 14.
With this new syntax we want a clean break from the current limitations to
On Tue, 18 Apr 2023 at 17:13, Jonathan Wakely wrote:
>
> On Tue, 18 Apr 2023 at 16:59, Jonathan Wakely via Libstdc++
> wrote:
> > diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
> > b/libstdc++-v3/config/abi/pre/gnu.ver
> > index 4ae63094eb7..7c015524b62 100644
> > --- a/libstdc++-v3/config/abi
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
-mno-inline-a
I will push this when a final round of testing finishes on x86-64 Linux.
gcc/ChangeLog:
* value-range.h (Value_Range::Value_Range): Avoid pointer sharing.
---
gcc/value-range.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/gcc/value-range.h b/gcc/value
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 18, 2023 11:38 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de;
> j...@ventanamicro.com
> Subject: Re: [PATCH 1/3]middle-end match.pd: don't emit label if not needed
>
> On Tue, Apr 18, 2023
On 4/18/23 08:28, Patrick O'Neill wrote:
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified
INSERTPS can select any element from src and insert into any place
of the dest. For SSE4.1 targets, compiler can generate e.g.
insertps $64, %xmm0, %xmm1
to insert element 1 from %xmm1 to element 0 of %xmm0.
gcc/ChangeLog:
PR target/94908
* config/i386/i386-builtin.def (__builtin_i
On 4/17/23 15:27, Uros Bizjak via Gcc-patches wrote:
These two predicates are similar to existing HARD_REGISTER_P and
HARD_REGISTER_NUM_P predicates and return 1 if the given register
corresponds to a virtual register.
gcc/ChangeLog:
* rtl.h (VIRTUAL_REGISTER_P): New predicate.
(VI
On Mon, Apr 17, 2023 at 11:27:28PM +0200, Uros Bizjak via Gcc-patches wrote:
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -1972,6 +1972,13 @@ set_regno_raw (rtx x, unsigned int regno, unsigned int
> nregs)
> /* 1 if the given register number REG_NO corresponds to a hard register. */
> #define HARD_
committed to trunk and gcc 13
On Tue, Apr 18, 2023 at 9:29 PM Jeff Law wrote:
>
>
>
> On 4/18/23 04:16, Kito Cheng via Gcc-patches wrote:
> > Document which version of RISC-V vector intrinsics has implemented in
> > GCC.
> >
> > gcc/ChangeLog:
> >
> > * doc/extend.texi (Target Builtins): Ad
Generated pdf inspected. Ok to commit?
Thoughts on fixing the IMHO wart to also expose all
replacements to all define_peephole2? Looks feasible
(famous last words), but then again I haven't checked the
history yet.
-- >8 --
I was a bit surprised when my define_peephole2 didn't match,
but it was
Thanks Kito I will look into this.
On 4/18/23 10:26, Kito Cheng wrote:
I would prefer drop this patch from this patch series since I believe
https://patchwork.ozlabs.org/project/gcc/patch/20230414014518.15458-1-juzhe.zh...@rivai.ai/
is the right fix for this issue.
On Tue, Apr 18, 2023 at 2:40
when debugging expmed.[ch] for PR/108987 saw that some of the cost arrays have
less than ideal layout as follows:
x_shift*cost[0..63][speed][modes]
We would want speed to be first index since a typical compile will have
that fixed, followed by mode and then the shift values.
It should be non-
Few more background about RVV:
RISC-V has provide different VLEN configuration by different ISA
extension like `zve32x`, `zve64x` and `v`
zve32x just guarantee the minimal VLEN is 32 bits,
zve64x guarantee the minimal VLEN is 64 bits,
and v guarantee the minimal VLEN is 128 bits,
Current status (
On 4/10/23 04:56, Lin Sinan wrote:
From: Sinan Lin
tell gcc that zbkb has these two spn to enable some optimizations. e.g.
1) the rrotate_expr could match to rotrm3 during expand; 2) hook up
__builtin_bswap64 with `rev8` in zbkb64.
Thanks. I pushed this to the trunk.
jeff
I'm not sure about the meaning of part of this. "...resumes at the last
generated insn." Does that mean:
1. If a match is found at some insn, the replacement defined by the matching
define_peephole2 is performed, and then the scan resumes at the first of the
insns produced by the replacement.
On 4/18/23 08:36, Vineet Gupta wrote:
[partial addressing of PR/109279]
RISCV splitters have restrictions to not create pesudos due to a combine
limitatation. And despite this being a split-during-combine limitation,
all split passes take the hit due to way define*_split are used in gcc.
Wit
On 4/17/23 10:38, Kevin Lee wrote:
This patch properly guards gcc_assert (multiple_p (m_full_nelts,
m_npatterns)) in vec_perm_indices indices (sel, 2, nelt) for VNx1 vectors.
Based on the feedback from Richard Biener and Richard Sandiford,
multiple_p has been used instead of maybe_lt to compa
> From: Paul Koning
> Date: Tue, 18 Apr 2023 14:32:07 -0400
>
> I'm not sure about the meaning of part of this.
> "...resumes at the last generated insn." Does that mean:
(Neither...)
> 1. If a match is found at some insn, the replacement
> defined by the matching define_peephole2 is perform
On 4/17/23 20:03, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function.
(pass_vsetvl::cleanup_insns): Fix bug.
ChangeLog should reference the bug number, like this:
PR target/109535
On 4/18/23 11:36, Jeff Law wrote:
On 4/18/23 08:36, Vineet Gupta wrote:
[partial addressing of PR/109279]
RISCV splitters have restrictions to not create pesudos due to a combine
limitatation. And despite this being a split-during-combine limitation,
all split passes take the hit due to wa
On 3/14/23 15:21, Eugene Rozenfeld wrote:
From 1808fe371ab5618b7c0ce22c0dbecdaf593e516d Mon Sep 17 00:00:00 2001
From: Eugene Rozenfeld
Date: Mon, 21 Nov 2022 13:33:38 -0800
Subject: [PATCH] Fix autoprofiledbootstrap build
1. Fix gcov version
2. Merge perf data collected when compiling the c
Hi Jeff, Ju-Zhe:
Let you know that I am running creduce with this testcase for reduce
the size of testcsae, it's really too huge...
On Wed, Apr 19, 2023 at 3:00 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/17/23 20:03, juzhe.zh...@rivai.ai wrote:
> > From: Ju-Zhe Zhong
> >
> > gcc/ChangeLog:
On 4/11/23 10:21, Patrick Palka wrote:
On Thu, 26 Jan 2023, Jason Merrill wrote:
On 1/25/23 15:35, Patrick Palka wrote:
On Tue, 17 Jan 2023, Jason Merrill wrote:
On 1/9/23 14:25, Patrick Palka via Gcc-patches wrote:
On Mon, 9 Jan 2023, Patrick Palka wrote:
On Wed, 5 Oct 2022, Patrick Palk
This moves around the code for tree_ssa_cs_elim slightly
improving code readability and removing declarations that
are no longer needed.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Remove declaration.
On Tue, 18 Apr 2023, Jason Merrill wrote:
> On 4/11/23 10:21, Patrick Palka wrote:
> > On Thu, 26 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/25/23 15:35, Patrick Palka wrote:
> > > > On Tue, 17 Jan 2023, Jason Merrill wrote:
> > > >
> > > > > On 1/9/23 14:25, Patrick Palka via Gcc-patches wro
On 4/18/23 13:21, Andrew Pinski via Gcc-patches wrote:
This moves around the code for tree_ssa_cs_elim slightly
improving code readability and removing declarations that
are no longer needed.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-
On 4/2/23 15:33, Sam James wrote:
gcc/ChangeLog:
* system.h: Drop unused INCLUDE_PTHREAD_H.
THanks. I've pushed this to the trunk.
jeff
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data", respectively.
For the testcase gfortran.dg/reshape_8.f90 I
Christophe Lyon via Gcc-patches writes:
> When I committed the patches to enable support for DFP on AArch64, I
> forgot to update the installation documentation.
>
> This patch adds AArch64 as needed (same as i386/x86_64).
>
> OK for trunk and gcc-13?
OK for both, thanks.
Richard
> 2023-04-17
On 11/20/22 09:54, Mark Harmstone wrote:
On 20/11/22 16:43, Jeff Law wrote:
On 10/26/22 21:38, Mark Harmstone wrote:
Changed to double dashes as per
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604287.html.
What value is there in providing this option now? IIUC we don't have
a
On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Yep, if I drop the non-canonicial strings via
diff --git a/gcc/config/riscv/multilib-generator
b/gcc/config/riscv/multilib-generator
index 58b7198b243..a63a4d69c18 100755
--- a/gcc/config/riscv/multilib-generat
On 1/10/23 21:20, Takayuki 'January June' Suwa via Gcc-patches wrote:
Currently, cond_move_process_if_block() does the conversion without
balancing the cost of the converted sequence with the original one, but
this should be checked by calling targetm.noce_conversion_profitable_p().
Doing so
On Tue, 18 Apr 2023 09:39:13 PDT (-0700), Patrick O'Neill wrote:
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Beha
On 4/18/23 15:57, Jeff Law via Gcc-patches wrote:
On 11/20/22 09:54, Mark Harmstone wrote:
On 20/11/22 16:43, Jeff Law wrote:
On 10/26/22 21:38, Mark Harmstone wrote:
Changed to double dashes as per
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604287.html.
What value is there in
On Tue, Apr 18, 2023 at 07:35:44AM -0600, Jeff Law wrote:
>
>
> On 4/18/23 03:06, Jakub Jelinek wrote:
> > Hi!
> >
> > While we've agreed this is not the right fix for the PR109040 bug,
> > the patch clearly improves generated code (at least on the testcase from the
> > PR), so I'd like to propo
On Tue, Apr 18, 2023 at 01:33:47PM +0200, Aldy Hernandez wrote:
> > > + const irange &r = as_a (v);
> > > + if (r.varying_p ())
> > > + hstate.add_int (VR_VARYING);
> > > + else
> > > + hstate.add_int (VR_RANGE);
> >
> > Shouldn't this also
> >hstate.add_int (r.num_pairs ()
when debugging expmed.[ch] for PR/108987 saw that some of the cost arrays have
less than ideal layout as follows:
x_shift*cost[0..63][speed][modes]
We would want speed to be first index since a typical compile will have
that fixed, followed by mode and then the shift values.
It should be non-
On 4/18/23 09:59, Jeff Law wrote:
On 4/18/23 08:28, Patrick O'Neill wrote:
...
+ rtx addr = force_reg (Pmode, XEXP (mem, 0));
+
+ rtx aligned_addr = gen_reg_rtx (Pmode);
+ emit_move_insn (aligned_addr, gen_rtx_AND (Pmode, addr,
+ gen_int_mode (-4, Pmode)));
So rather
On 4/18/23 14:32, Jason Merrill wrote:
On 4/18/23 15:57, Jeff Law via Gcc-patches wrote:
On 11/20/22 09:54, Mark Harmstone wrote:
On 20/11/22 16:43, Jeff Law wrote:
On 10/26/22 21:38, Mark Harmstone wrote:
Changed to double dashes as per
https://gcc.gnu.org/pipermail/gcc-patches/2022-Oc
On 4/18/23 14:48, Patrick O'Neill wrote:
On 4/18/23 09:59, Jeff Law wrote:
On 4/18/23 08:28, Patrick O'Neill wrote:
...
+ rtx addr = force_reg (Pmode, XEXP (mem, 0));
+
+ rtx aligned_addr = gen_reg_rtx (Pmode);
+ emit_move_insn (aligned_addr, gen_rtx_AND (Pmode, addr,
+
This patch adds the scheduling model for Neoverse N1, based on the information
from the "Arm Neoverse N1 Software Optimization Guide”.
--
Evandro Menezes
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def:
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
-mno-inline-a
This patch adds the cost model for Neoverse N1, based on the information from
the "Arm Neoverse N1 Software Optimization Guide”.
--
Evandro Menezes
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Use th
Yes, like kito said.
We won't enable VNx1DImode in auto-vectorization so it's meaningless to fix it
here.
We dynamic adjust the minimum vector-length for different '-march' according to
RVV ISA specification.
So we strongly suggest that we should drop this fix.
Thanks.
juzhe.zh...@rivai.ai
F
>> ChangeLog should reference the bug number, like this:
>> PR target/109535
>> Seems like this ought to be static. Though it's not clear why
>> count_occurrences didn't do what you needed. Can you explain why
>> count_occurrences was insufficient for your needs?
Address comment, I will resend a
On 4/17/23 12:36, Michael Collison wrote:
2023-03-02 Michael Collison
Juzhe Zhong
* config/riscv/riscv.md (riscv_vector_preferred_simd_mode): Include
vector-iterators.md.
* config/riscv/vector-auto.md: New file containing
autovectorization patt
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/extensions.xml: Fix example to declare and
qualify std::free, and use NULL instead of 0.
* doc/html/manual/ext_demangling.html: Regenerate.
* libsupc++/cxxabi.h: Adjust doxygen
Juzhe and Kito,
Thank you for the clarification.
On 4/18/23 18:48, juzhe.zh...@rivai.ai wrote:
Yes, like kito said.
We won't enable VNx1DImode in auto-vectorization so it's meaningless
to fix it here.
We dynamic adjust the minimum vector-length for different '-march'
according to RVV ISA spec
From: Ju-Zhe Zhong
Fix bug reported by google/highway who is using rvv intrinsic:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
PR 109535
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function.
(pass_vsetvl::cleanup_insns): Fix bug.
After a phiopt change, I got a failure of cmov9.c.
The RTL IR has zero_extend on the outside of
the if_then_else rather than on the side. Both
ways are considered canonical as mentioned in
PR 66588.
This fixes the failure I got and also adds a testcase
which fails before even my phiopt patch but w
Hi Richard, Jeff:
It's it possible to backport to GCC 13? highway is one of our
important users for RISC-V vector stuff, and it has built in some
distro, so we believe this bug fix is important to backport.
Thanks
Hi Ju-Zhe:
Thanks for update
On Wed, Apr 19, 2023 at 7:25 AM wrote:
>
> From: J
Do you mind shared gcc configure and the option you tried?
On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> >> Yep, if I drop the non-canonicial strings via
> >>
> >> diff --git a/gcc/config/riscv/multilib-gen
On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
Do you mind shared gcc configure and the option you tried?
Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux".
On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote:
On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patch
Could you please move the new function declarations and new code to
the patch where they are being used?
> +/* RVV vector register sizes. */
> +enum riscv_vector_bits_enum
> +{
> + RVV_SCALABLE,
> + RVV_NOT_IMPLEMENTED = RVV_SCALABLE,
> + RVV_64 = 64,
> + RVV_128 = 128,
> + RVV_256 = 256,
>
On 4/18/23 18:18, Kito Cheng wrote:
Hi Richard, Jeff:
It's it possible to backport to GCC 13? highway is one of our
important users for RISC-V vector stuff, and it has built in some
distro, so we believe this bug fix is important to backport.
I want to see an explanation why count_occurrences
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data", res
The bug issue reported by google/highway project:
(set(..)
(reg:QI s0)
(reg:DI s0))
The "avl" operand rtx = (reg:DI s0)
count_occurrences return 1 however the actual regno occurrences should be 2.
In this case, the VSETVL PASS will eliminate the use of (reg:DI s0) then file
> +/* Implement TARGET_ESTIMATED_POLY_VALUE.
> + Look into the tuning structure for an estimate.
> + KIND specifies the type of requested estimate: min, max or likely.
> + For cores with a known RVV width all three estimates are the same.
> + For generic RVV tuning we want to distinguish th
On 4/18/23 19:04, juzhe.zh...@rivai.ai wrote:
The bug issue reported by google/highway project:
(set(..)
(reg:QI s0)
(reg:DI s0))
The "avl" operand rtx = (reg:DI s0)
count_occurrences return 1 however the actual regno occurrences should be 2.
In this case, the VSETVL PASS wil
> @@ -118,6 +120,41 @@ const_vec_all_same_in_range_p (rtx x, HOST_WIDE_INT
> minval,
> && IN_RANGE (INTVAL (elt), minval, maxval));
> }
>
> +/* Return the vlmul field for a specific machine mode. */
> +unsigned int
> +riscv_classify_vlmul_field (enum machine_mode mode)
This is not imp
> diff --git a/gcc/config/riscv/vector-iterators.md
> b/gcc/config/riscv/vector-iterators.md
> index 70ad85b661b..7fae87968d7 100644
> --- a/gcc/config/riscv/vector-iterators.md
> +++ b/gcc/config/riscv/vector-iterators.md
> @@ -34,6 +34,8 @@
>UNSPEC_VMULHU
>UNSPEC_VMULHSU
>
> + UNSPEC_VA
And which -march -mabi you used will got issue?
On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
> > Do you mind shared gcc configure and the option you tried?
>
> Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux"
On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote:
And which -march -mabi you used will got issue?
On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote:
On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
> Do you mind shared gcc configure and the option you tried?
Just risc
I tried refers_to_regno_p
It can not work for us since it just return true or false whether the "rtx" has
the regno.
In our situation, we remove "AVL" dependency when it appears once in the "rtx"
otherwise, we don't eliminate "AVL" dependency.
Would you mind giving me more suggestions?
Thanks
Meaning when "AVL" is a reg and appears once, we will eliminate "AVL" operand
in uses.
If it appears more than once, we don't eliminate the "AVL" operand in uses.
You can this case:
vint8m1_t b = __riscv_vadd_vx_i8m1 (a, vl, vl);
Here you can see "vl" variable not only serves as the "AVL" which
OK, thanks, I know what the problem is, I tried rv64 but didn't try
rv32, I have another fix in my mind, and will post another fix soon.
On Wed, Apr 19, 2023 at 9:29 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote:
> > And which -march -mabi you used will g
On Tue, Apr 18, 2023 at 3:07 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/i386-common.cc
> (OPTION_MASK_ISA_AVX512BITALG_SET):
> Change OPTION_MASK_ISA_AVX512F_SET
> to OPTION_MASK_ISA_AVX512BW_SET.
> (OPTION_MASK_ISA_A
On Tue, Apr 18, 2023 at 3:07 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/i386-common.cc
> (OPTION_MASK_ISA_AVX512VBMI2_SET): Change OPTION_MASK_ISA_AVX512F_SET
> to OPTION_MASK_ISA_AVX512BW_SET.
> (OPTION_MASK_ISA_AVX512F_UNSE
On Tue, Apr 18, 2023 at 2:52 PM Hu, Lin1 via Gcc-patches
wrote:
>
> Hi, all
>
> The patch aims to optimize vshuf{i,f}{32x4,64x2} ymm and vperm{i,f}128.
> And it has regtested on x86_64-pc-linux-gnu. OK for trunk?
Ok.
>
> Thanks.
> Lin
>
> vshuf{i,f}{32x4,64x2} ymm and vperm{i,f}128 ymm are 3 clk.
On Tue, Apr 18, 2023 at 3:13 PM Hu, Lin1 via Gcc-patches
wrote:
>
> More details: Intrinsics guide add these 128/256-bit intrinsics as follow:
> https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=reduce_&ig_expand=5814.
>
> So we intend to enable these intrinsics for GC
On Tue, Apr 18, 2023 at 3:15 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> For vpblendm{b,w}, they actually do not have constant parameters.
> Therefore, there is no need for them been wrapped in __OPTIMIZE__.
>
> Also, we should check TARGET_AVX512VL for 128/256 bit vectors in patterns.
On Tue, Apr 18, 2023 at 3:18 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently in GCC, the 128 bit intrin for instruction vpclmulqdq is
> under PCLMUL ISA. Because there is no dependency between ISA set PCLMUL
> and VPCLMULQDQ, The 128 bit intrin is not available when we just use
>
On Wed, Apr 19, 2023 at 9:54 AM Hongtao Liu wrote:
>
> On Tue, Apr 18, 2023 at 3:18 PM Haochen Jiang via Gcc-patches
> wrote:
> >
> > Hi all,
> >
> > Currently in GCC, the 128 bit intrin for instruction vpclmulqdq is
> > under PCLMUL ISA. Because there is no dependency between ISA set PCLMUL
> >
Hi,
On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.
Like Like PR65484 and PR87306, this patch use vect_hw_misalig to guard
the case on powerpc targets.
Tested on ppc64{le,} and x86_64.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/testsuite/Cha
Re-order i386 cpuid based on the order of CPUID.
gcc/ChangeLog:
* config/i386/cpuid.h: Open a new section for Extended Features
Leaf (%eax == 7, %ecx == 0) and Extended Features Sub-leaf (%eax == 7,
%ecx == 1).
---
gcc/config/i386/cpuid.h | 35 +++-
Jeff Law writes:
> On 4/2/23 15:33, Sam James wrote:
>> gcc/ChangeLog:
>> * system.h: Drop unused INCLUDE_PTHREAD_H.
> THanks. I've pushed this to the trunk.
Cheers Jeff!
> jeff
best,
sam
signature.asc
Description: PGP signature
> -Original Message-
> From: Mo, Zewei
> Sent: Wednesday, April 19, 2023 10:03 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] Re-arrange sections of i386 cpuid
>
> Re-order i386 cpuid based on the order of CPUID.
>
> gcc/ChangeLog:
>
>
On Tue, Apr 18, 2023 at 2:57 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently in i386, we have several ISAs share builtin between each other
> which is handled in ix86_check_builtin_isa_match with if condition clauses.
>
> The patterns for these clauses are quite similar so it wil
On Tue, Apr 18, 2023 at 3:19 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently in GCC, the 128 bit intrin for instruction vaes{end,dec}{last,}
> is under AES ISA. Because there is no dependency between ISA set AES
> and VAES, The 128 bit intrin is not available when we use compiler
> > a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index
> > 33e281901cf..e7d565a8389 100644
> > --- a/gcc/config/i386/sse.md
> > +++ b/gcc/config/i386/sse.md
> > @@ -25107,67 +25107,71 @@
> >
> > ;;
> > ;;
> >
> > (define_insn
On Mon, 17 Apr 2023 23:10:03 PDT (-0700), richard.guent...@gmail.com wrote:
On Mon, Apr 17, 2023 at 8:22 PM Palmer Dabbelt wrote:
These had been approved for trunk, but I hadn't gotten around to
committing them before the branch. They're on trunk now. They're all
pretty trivial test suite fi
Hi Haochen,
on 2023/4/18 11:13, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
> This patch adds ppc_cpu_supports_hw into explicit name checking in
> proc is-effective-target-keyword. So ppc_cpu_supports_hw can be used
> as a target selector in test directives.
I think this is the prerequisite of th
> -Original Message-
> From: Jiang, Haochen
> Sent: Wednesday, April 19, 2023 10:41 AM
> To: Hongtao Liu
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: RE: [PATCH] i386: Share AES xmm intrin with VAES
>
> > > a/gcc/config/i386/sse.md b/gcc/config/i386/sse.
Hi Haochen,
on 2023/4/18 11:13, HAO CHEN GUI wrote:
> Hi,
> This patch xfails a float128 comparison test case on powerpc64
> that fails due to a longstanding issue with floating-point
> compares.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more
> information.
>
> The cas
v5: Refine patch and send this for gcc14 stage1.
v4: Address comments.
4.1. Handle GIMPLE_GOTO and GIMPLE_ASM.
4.2. Fix failure of limit-caselabels.c (labels on same line),
pointer_array_1.f90 (unused labels) etc.
v3: Add compute_target_labels and call it in the front of make_blocks_1.
v2: Che
Hi Jeff,
on 2023/4/19 10:03, Jiufu Guo wrote:
> Hi,
>
> On P7, option -mno-allow-movmisalign is added during testing, which
> prevents slp happen on the case.
>
> Like Like PR65484 and PR87306, this patch use vect_hw_misalig to guard
Dup like... ~~ missing the
在 2023/4/12 下午8:16, Xi Ruoyao 写道:
We'd been generating really bad block move sequences which is recently
complained by kernel developers who tried __builtin_memcpy. To improve
it:
1. Take the advantage of -mno-strict-align. When it is set, set mode
size to UNITS_PER_WORD regardless of th
> From: Hans-Peter Nilsson
> Date: Tue, 18 Apr 2023 20:44:12 +0200
>
> > From: Paul Koning
>
> > Date: Tue, 18 Apr 2023 14:32:07 -0400
> >
> > I'm not sure about the meaning of part of this.
> > "...resumes at the last generated insn." Does that mean:
[...]
> (Neither...)
[...]
> Sorry, y
From: Pan Li
This patch try to adjust the RISC-V Vector RTL for the
generic shortcut optimization for RVV integer compare.
It includes compare operator eq, ne, ltu, lt, leu, le,
gtu, gt, geu and ge.
Assume we have below test code.
vbool1_t test_shortcut_for_riscv_vmslt_case_0(vint8m8_t v1, size_
Write a primary version for that, did you mind giving it a try?
The basic idea is to select multilib only by ABI, so that we don't
need to bother with endless multilib reuse cases...
On Wed, Apr 19, 2023 at 9:38 AM Kito Cheng wrote:
>
> OK, thanks, I know what the problem is, I tried rv64 but di
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 05:15:27 +0200
> Approvers: pdf output reviewed. Ok to commit?
Patch retracted, at least temporarily. My "understanding"
may be clouded by looking at an actual bug. Sigh.
brgds, H-P
On 4/18/23 19:29, juzhe.zh...@rivai.ai wrote:
I tried refers_to_regno_p
It can not work for us since it just return true or false whether the
"rtx" has the regno.
Use refers_to_regno_p instead of the equality comparison for the REGNO.
So you're still going to have count_regno_occurrences, y
On Thu, Apr 6, 2023 at 1:07 PM Liu, Hongtao via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Vladimir Makarov
> > Sent: Wednesday, April 5, 2023 8:59 PM
> > To: Jeff Law ; Liu, Hongtao
> > ; gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] Check hard_regno_mode_ok before sett
On Tue, 18 Apr 2023, Lulu Cheng wrote:
> v1 -> v2: Modify syntax errors and description information.
> v2 -> v3: Modify some description information.
Thank you, and thank you to Xuerui for their feedback!
Please go ahead and push this.
Gerald
1 - 100 of 230 matches
Mail list logo
