Hi,
As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P (mode))"
in "try_const_anchors".
This assert seems correct because the function try_const_anchors cares
about integer values currently, and modes other than SCALAR_INT_MODE_P
are not needed to support.
This patch makes sure
On Tue, Jun 6, 2023 at 4:23 PM liuhongt wrote:
>
> > I think this is a better patch and will always be correct and still
> > get folded at the gimple level (correctly):
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index d4ff56ee8dd..02bf5ba93a5 100644
> > ---
On Wed, Jun 7, 2023 at 8:31 AM Hongtao Liu wrote:
>
> On Tue, Jun 6, 2023 at 10:36 PM Uros Bizjak wrote:
> >
> > On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote:
> > >
> > > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
> > > >
> > > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all optimization levels.
OK? Bootstrapped and tested on
On 5/25/23 06:35, Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
calculations, documentation and testcases.
gcc/ChangeLog:
* config.gcc: Add riscv-fold-mem-offsets.o to extra_objs.
* config/riscv/riscv-passes.def
> Date: Wed, 7 Jun 2023 18:06:15 -0400
> From: Jason Merrill via Gcc-patches
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Now that we support NRV from an inner block, we can also support non-NRV
> returns from other blocks, since once the NRV is out of scope a later
Hi Maxim,
I managed to nail the bug on the failing test pr100244.C, as I did too
observe a divergence after my patch.
For pr101962.c, it was simply a dg-note I forgot to remove, that made it
fail, since the related warning is no longer relevant. The behavior
otherwise is as expected before and
Hi David,
So first real committed patch actually was a misstep. So I'm currently
fixing that.
The issue is that the original idea, to return a boolean and create a
unknown_svalue on OOB access to prevent further "use-of-uninitialized-value"
caused a loss of information on the location of the
On 6/8/23 15:54, Patrick Palka wrote:
On Wed, 7 Jun 2023, Jason Merrill wrote:
On 6/6/23 14:29, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with
If anyone is so inclined, the patches in the following
PR's can be committed and the PR closed. These are
patches for gfortran.
69101 91960 95613 99139 99368 99798
100607 103795 103796 104626 105594 101967
101951 104649 106050 106500 107266 107406
107596
This is an opportunity for
On Wed, 7 Jun 2023, Jason Merrill wrote:
> On 6/6/23 14:29, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > In the second testcase of PR110122, during regeneration of the generic
> > lambda with V=Bar{},
Range_operator and range_operator_float are 2 different classes, which
was not the original intent. This makes generalized dispatch to the
appropriate function more difficult. The distinction between what is a
float operator and what is an integral operator also blurs when some
methods have
This patch introduces a new dispatch mechanism for range_op_handler.
Instead of ad-hoc if then elses based on is_a and is_a,frange
*>, the discriminators in class vrange are used for each operand to
create a triplet, ie (III for "LHS = Irange, op1 = Irange, op2 =
Irange", and IFI for "Irange
Range_operator had a tree code added last release to facilitate bitmask
operations. This was intended to be a temporary change until we could
figure out something more strategic going forward.
This patch removes the tree_code and replaces it with a virtual routine
to perform the masking.
We currently do not have any floating point operators where operand 1 is
a different type than the LHS. When we eventually do there is a bug in
fold_range. If either operand is a known NAN, it returns a NAN of the
type of operand 1 instead of the result type.
This patch sets it to the correct
> Begin forwarded message:
>
> From: Jason Merrill
> Subject: Re: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers
> Date: 8 June 2023 at 19:06:36 BST
> To: Alex Coplan , gcc-patches@gcc.gnu.org
> Cc: Nathan Sidwell , Iain Sandoe
>
> On 6/8/23 07:06, Alex Coplan wrote:
>> Hi,
Hi,
Yes of course, I tested many days ago since regtesting takes several days
on my box, I should have retested !
But I got an account for the compile farm today, so I'm on it immediately,
I also see a divergence in the warnings on my box.
Thanks for the report !
Sincerely sorry,
Benjamin.
On
Hi Steve,
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
[...]
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16),
On 6/8/23 07:06, Alex Coplan wrote:
Hi,
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Upstream LLVM can be made to accept the above construct with
> On Jun 7, 2023, at 00:50, Ben Boeckel via Gcc-patches
> wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
>
The manual is incorrect in saying that the option does not warn
about designated initializers, which it does in C++. Whether the
divergence in behavior is desirable is another thing, but let's
at least make the manual match the reality.
PR c/39589
PR c++/96868
gcc/ChangeLog:
> On Jun 6, 2023, at 15:48, Benjamin Priour via Gcc-patches
> wrote:
>
> From: Benjamin Priour
>
> This patch enchances -Wanalyzer-out-of-bounds that is no longer paired
> with a -Wanalyzer-use-of-uninitialized-value on out-of-bounds-read.
>
> This also fixes PR analyzer/109437.
> Before
Le 08/06/2023 à 11:58, Tamar Christina via Gcc-patches a écrit :
Hi,
New version of the patch, I've omitted the explanation again
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Hello,
this is not my area of expertise, but I saw the following:
+ /*
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90
Kewen:
On Wed, 2023-06-07 at 17:36 +0800, Kewen.Lin wrote:
> Hi,
>
> on 2023/6/7 03:54, Carl Love wrote:
> > On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote:
> > > Hi Carl,
> > >
> > > on 2023/5/2 23:52, Carl Love via Gcc-patches wrote:
> > > > GCC maintainers:
> > > >
> > > > The
Kewen, GCC maintainers:
Version 3, was able to get the overloaded version of scalar_insert_exp
to work and the change to xsxexpqp_f128_ define instruction to
work with the suggestions from Kewen.
Version 2, I have addressed the various comments from Kewen. I had
issues with adding an
> > I'd very much like to see the condops go into GCC as well, but I've been
> > hesitant to move it forward myself. We're still waiting on hardware and
> > it wasn't clear to me that we really had consensus agreement to move the
> > bits forward based on an announcement vs waiting on actual
Committed as passed all riscv.exp rvv.exp tests, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, June 8, 2023 10:01 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; rdapp@gmail.com; Wang, Yanzhang
; kito.ch...@gmail.com
Subject: Re: [PATCH v2]
On 6/6/23 21:50, Wang, Yanzhang wrote:
Hi Jeff,
Thanks your comments. I have few questions that I don't quite understand.
One of the things that needs to be upstreamed is long jump support within
a function. Essentially once a function reaches 1M in size we have the
real possibility that
Hi all,
This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE
codes.
The semantics are a clamping operation on the argument with the min and max of
the narrow mode,
followed by a truncation. The signedness of the clamp and the min/max extrema
is derived from
the
On Thu 8. Jun 2023 at 16:17, Jeff Law wrote:
>
>
> On 6/8/23 04:22, Kito Cheng wrote:
>
> >
> >
> > Oh, okay I got the awkness point...I am ok with that on gcc land, but I
> > would like binutils support that first, or remove the extension from the
> > mcpu for temporary before binutils support,
C++ requires inline functions to be declared inline and defined in
every translation unit that uses them. frange_nextafter is used in
gimple-range-op.cc but it's only defined as inline in
range-op-float.cc. Drop the extraneous inline specifier.
Other non-static inline functions in
In addition to Andreas's and Richard's comments:
Tamar Christina writes:
> +@item
> +@samp{@{@@} is followed by a layout in parentheses which is @samp{cons:}
> followed by
> +a list of @code{match_operand}/@code{match_scratch} comma operand numbers,
> then a
How about:
a comma-separated
On 6/8/23 04:22, Kito Cheng wrote:
Oh, okay I got the awkness point...I am ok with that on gcc land, but I
would like binutils support that first, or remove the extension from the
mcpu for temporary before binutils support, otherwise it just a broken
support for that CPU on trunk gcc.
On Thu, Jun 8, 2023 at 9:13 AM Jonathan Wakely wrote:
>
> On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
>>
>>
>> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> Middle-end folks: any thoughts about how best to make the change
>>>
On 6/8/23 01:52, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add new test cases to make sure the
RVV FP16 works well as expected.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvfh-intrinsic.c: Add new cases.
*
I like JuZhe's proposal too since it's a less invasive way :)
On Thu, Jun 8, 2023 at 9:18 PM Li, Pan2 via Gcc-patches
wrote:
>
> Thanks Juzhe for the idea. It looks work well as we expected, with the
> following try.
>
>
> 1. Allow all FP=16 types for vfadd, then _zvfh and _zvfhmin will be
Thanks Juzhe for the idea. It looks work well as we expected, with the
following try.
1. Allow all FP=16 types for vfadd, then _zvfh and _zvfhmin will be OK.
2. Add restriction define_attr as juzhe mentioned, then _zvfh works well,
and _zvfhmin will meet error like unsatisfied insn.
I
On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
>
> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> Middle-end folks: any thoughts about how best to make the change
>> described in
>> the last paragraph below?
>>
>> Library folks: any
> On Jun 7, 2023, at 6:05 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Are you suggesting to use identifier directly as the argument of the
>> attribute?
>> I tried this in the beginning, however, the current parser for the attribute
>> argument can
On 01/06/2023 05:26, YunQiang Su wrote:
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
*
Hi FX,
Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches:
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
I just
On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov
wrote:
> Hi Jonathan,
>
> Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu
> on SPEC CPU2017's 641.leela_s benchmark [1].
>
> In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212
> bytes. This seems like a
Hi FX,
Having a POWER system isn't enough, it also needs the IBM "advance
toolchain", and (at least with current distros, which default to
ibm long double), you need to dance counterclockwise three
times... I mean you need to invoke configure with some special magic
Thanks for the frank
Hi,
This patch fixes the problem that the loop in the tsvc s176 function is
optimized and removed because `iterations/LEN_1D` is 0 (where iterations
is set to 1, LEN_1D is set to 32000 in tsvc.h).
This testcase passed on x86 and AArch64 system.
Best,
Lehua
gcc/testsuite/ChangeLog:
Hi,
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Upstream LLVM can be made to accept the above construct with
-Wno-error=elaborated-enum-base.
This macro
On 08/06/2023 11:00, Tamar Christina via Gcc-patches wrote:
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches):
From: oluade01
This patch adds new RTL and tests for sabd and uabd
PR tree-optimization/109156
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (sabd, uabd):
Change the mode to 3.
* config/aarch64/aarch64-simd.md (aarch64_abd):
Rename to abd3.
> It would be good to add a:
>
> /* { dg-final { scan-assembler-not {\tabs\t} } } */
>
> to be the positive tests, to make it more obvious that all separate
> ABS instructions are elided.
Done.
Patch is in the next response.
On 08/06/2023 11:29, Richard Earnshaw (lists) via Gcc-patches wrote:
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
From: oluade01
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.texi (sabd, uabd): Document them.
* internal-fn.def (ABD): Use new optab.
* optabs.def (sabd_optab, uabd_optab): New optabs,
*
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
+@node Compact Syntax
+@section Compact Syntax
+@cindex compact
New patch to address issue brought up in a different
thread: mptjzwgplp2@arm.com
> > + /* Failed to find a widen operation so we check for a regular
> > MINUS_EXPR. */
> > + if (diff
> > + && gimple_assign_rhs_code (diff) == MINUS_EXPR
> > + && (TYPE_UNSIGNED (abs_type) ||
> 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
> > > +++
> Having a POWER system isn't enough, it also needs the IBM "advance
> toolchain", and (at least with current distros, which default to
> ibm long double), you need to dance counterclockwise three
> times... I mean you need to invoke configure with some special magic
Thanks for the frank
Hi together,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
> @@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
> multi-alternative template:
> @end group
> @end smallexample
>
> +@node Compact Syntax
> +@section Compact Syntax
> +@cindex compact syntax
> +
> +In cases where the
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches): Add nosimd.
(*mov_aarch64, *movsi_aarch64,
Hi,
New version of the patch, I've omitted the explanation again
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Thanks,
Tamar
gcc/ChangeLog:
* gensupport.cc (class conlist, add_constraints, add_attributes,
create_missing_attributes,
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
> > +++
> On May 25, 2023, at 03:30, Cui, Lili via Gcc-patches
> wrote:
>
> From: Lili Cui
>
> Make some changes in reassoc pass to make it more friendly to fma pass later.
> Using FMA instead of mult + add reduces register pressure and insruction
> retired.
>
> There are mainly two changes
> 1. Put
From: Benjamin Priour
For the record, below is the previous patch I submitted, with the
little formatting issues fixed - multiline docstring no ends on a newline.
It was otherwise validated by David Malcolm, so I already committed it.
This patch enhances -Wanalyzer-out-of-bounds that is no
On Thu, Jun 08, 2023 at 10:05:43AM +0100, Jonathan Wakely via Gcc-patches wrote:
> > Looking at assembly, one of the differences I see is that the "after"
> > version has calls to realloc_insert(), while "before" version seems to have
> > them inlined [2].
> >
> > [1]
> >
Thanks Gents!
The solution is to gfc_free_expr (p) if the replacement is not made.
I am regtesting a patch for PR107900. I'll include the fix for the
memory leak in the patch for that.
Cheers
Paul
On Thu, 8 Jun 2023 at 09:30, Harald Anlauf wrote:
>
> On 6/8/23 09:46, Mikael Morin wrote:
> >
On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov
wrote:
> Hi Jonathan,
>
> Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu
> on SPEC CPU2017's 641.leela_s benchmark [1].
>
> In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212
> bytes. This seems like a
Hi Jonathan,
Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu on
SPEC CPU2017's 641.leela_s benchmark [1].
In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212 bytes.
This seems like a corner-case; the rest of SPEC CPU2017 is, mostly, neutral to
this
I have an idea base on what Kito said.
We enable vfadd FP16 for TARGET_ZVFH. But we don't need to add TARGET_VECTOR &&
for each instruction.
We can reference riscv.md:
(define_attr "ext_enabled" "no,yes"
(cond [(eq_attr "ext" "base")
(const_string "yes")
(and (eq_attr "ext" "f")
On 6/8/23 09:46, Mikael Morin wrote:
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but
Looks doable up to a point, I will have a try and keep you posted.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, June 8, 2023 3:58 PM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches ; Robin
Dapp ; jeffreyalaw ; Wang, Yanzhang
Subject: Re: [PATCH v8] RISC-V: Refactor
Oh. Good suggestion. It's much better than my solution I think.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-06-08 15:58
To: juzhe.zh...@rivai.ai
CC: pan2.li; gcc-patches; Robin Dapp; jeffreyalaw; yanzhang.wang
Subject: Re: [PATCH v8] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.
I
I am thinking, is it possible to use mode attr to remove the overhead
of checking the mode for other FP modes other than FP16?
e.g.
(define_mode_attr TARGET_FP_FULL_OPERATION_CHECKING [
(VNx1HF "TARGET_ZVFH")
...
(VNx1SF "1")
...
])
"TARGET_VECTOR && riscv_vector::float_mode_supported_p
From: Pan Li
This patch would like to add new test cases to make sure the
RVV FP16 works well as expected.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvfh-intrinsic.c: Add new cases.
* gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c: New test.
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but his comment was about the case
Bootstrap && Regression PASSed
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-08 10:05
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V5] VECT: Add SELECT_VL support
From: Ju-Zhe Zhong
Co-authored-by: Richard Sandiford
Co-authored-by:
> 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-cores.def
> @@ -38,6 +38,7 @@ RISCV_TUNE("sifive-3-series", generic, rocket_tune_info)
>
On 2023/6/8 10:27, Lulu Cheng wrote:
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a
LGTM. Let's wait for Jeff and Robin. After this patch, we can start FP16
autovec.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-08 14:29
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v8] RISC-V: Refactor requirement of ZVFH and
Sure, update it in PATCH v8.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621016.html
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, June 8, 2023 2:09 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ; Li,
Pan2 ; Wang, Yanzhang
Subject: Re: [PATCH v7] RISC-V: Refactor
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN
Hi Jeff,
Yes that one has changed; I changed the implementation based on your feedback.
Thanks,
Manolis
On Thu, Jun 8, 2023 at 1:18 AM 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,
Rename float_point_mode_supported_p into float_mode_supported_p
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-08 14:06
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang
Subject: [PATCH v7] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.
From: Pan Li
This
Update the PATCH v7 (please help to ignore v6) for this change, thanks Juzhe
for the suggestion.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621012.html
Pan
From: Li, Pan2
Sent: Wednesday, June 7, 2023 4:43 PM
To: juzhe.zh...@rivai.ai; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ;
Wang,
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN
83 matches
Mail list logo
