On Wed, Aug 2, 2023 at 3:33 AM liuhongt wrote:
>
> In [1], I propose a patch to generate vmovdqu for all vlddqu intrinsics
> after AVX2, it's rejected as
> > The instruction is reachable only as __builtin_ia32_lddqu* (aka
> > _mm_lddqu_si*), so it was chosen by the programmer for a reason. I
> >
c-torture/execute/pr59014-2.c fails with the Zicond work on rv64. We
miscompile the "foo" routine because we have eliminated a required sign
extension.
The key routine looks like this:
foo (long long int x, long long int y)
{
if (((int) x | (int) y) != 0)
return 6;
return x + y;
}
Hi Richard,
Update the patch with a simple case (see below case and comments). It shows a
live stmt may not have reduction def, which introduce the ICE.
Is it OK for trunk?
Fix the assertion failure on empty reduction define in info_for_reduction.
Even a stmt is live, it may still have
From: Pan Li
This patch would like to support the rounding mode API for the VFWADD
VFSUB and VFRSUB as below samples.
* __riscv_vfwadd_vv_f64m2_rm
* __riscv_vfwadd_vv_f64m2_rm_m
* __riscv_vfwadd_vf_f64m2_rm
* __riscv_vfwadd_vf_f64m2_rm_m
* __riscv_vfwadd_wv_f64m2_rm
*
Hi Jeff,
Do you have any further comments about this patch ?
Thanks,
Yanzhang
> -Original Message-
> From: Jeff Law
> Sent: Friday, July 21, 2023 12:11 PM
> To: Kito Cheng ; Wang, Yanzhang
>
> Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com;
> Li, Pan2
>
On Tue, Aug 01, 2023 at 02:06:00 PM Jeff Law wrote:
>
>
>
>On 7/29/23 03:13, Xiao Zeng wrote:
>> This patch recognizes Zicond patterns when the select pattern
>> with condition eq or neq to 0 (using eq as an example), namely:
>>
>> 1 rd = (rs2 == 0) ? non-imm : 0
>> 2 rd = (rs2 == 0) ? non-imm :
This patch recognizes Zicond patterns when the select pattern
with condition eq or neq to 0 (using eq as an example), namely:
1 rd = (rs2 == 0) ? non-imm : 0
2 rd = (rs2 == 0) ? non-imm : non-imm
3 rd = (rs2 == 0) ? reg : non-imm
4 rd = (rs2 == 0) ? reg : reg
gcc/ChangeLog:
*
In [1], I propose a patch to generate vmovdqu for all vlddqu intrinsics
after AVX2, it's rejected as
> The instruction is reachable only as __builtin_ia32_lddqu* (aka
> _mm_lddqu_si*), so it was chosen by the programmer for a reason. I
> think that in this case, the compiler should not be too
AVX512FP16 supports vfmaddsubXXXph and vfmsubaddXXXph.
Also remove scalar mode from fmaddsub/fmsubadd pattern since there's
no scalar instruction for that.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready to push to trunk.
gcc/ChangeLog:
PR target/81904
*
On 2023-08-01 18:57, Kees Cook wrote:
return p;
}
/* in the following function, malloc allocated less space than size of the
struct fix. Then what's the correct behavior we expect
the __builtin_object_size should have for the following?
*/
static struct fix * noinline
On 2023-08-01 17:35, Qing Zhao wrote:
typedef struct
{
int a;
} A;
size_t f()
{
A *p = malloc (1);
return __builtin_object_size (p, 0);
Correction, that should be __builtin_object_size (p->a, 0).
Actually, it should be __builtin_object_size(p->a, 1).
For
On 8/1/23 17:38, Vineet Gupta wrote:
Also note that getting FP out of the shift-add sequences is the other
key goal of Jivan's work. FP elimination always results in a
spill/reload if we have a shift-add insn where one operand is FP.
Hmm, are you saying it should NOT be generating
On 8/1/23 16:27, Jeff Law wrote:
On 8/1/23 17:13, Vineet Gupta wrote:
On 8/1/23 16:06, Philipp Tomsich wrote:
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.
FWIW,
On 8/1/23 16:22, Jeff Law wrote:
They must not be working as expected or folks are using old trees.
Manolis's work for regcprop has been on the trunk for about 5-6 weeks
ag this point:
I have bleeding edge trunk from 2-3 days back. I think we are looking
for the following which the tree
On 8/1/23 17:13, Vineet Gupta wrote:
On 8/1/23 16:06, Philipp Tomsich wrote:
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.
FWIW, all 5 of them involve a SH2ADD have
On 8/1/23 17:06, Philipp Tomsich wrote:
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.
They must not be working as expected or folks are using old trees.
Manolis's work
On 8/1/23 17:03, Vineet Gupta wrote:
On 8/1/23 15:07, Philipp Tomsich wrote:
+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
On 8/1/23 16:06, Philipp Tomsich wrote:
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.
FWIW, all 5 of them involve a SH2ADD have SP as source in the fold FP
case which
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 wrote:
> > +Manolis Tsamis
> >
> >
On 8/1/23 15:07, Philipp Tomsich wrote:
+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.
On Tue, Aug 01, 2023 at 09:35:30PM +, Qing Zhao wrote:
>
>
> > On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote:
> >
> > On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
> >> On 2023-07-31 12:47, Qing Zhao wrote:
> >>> Hi, Sid and Jakub,
> >>>
> >>> I have a question in the following
On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote:
> /* In general, Due to type casting, the type for the pointee of a pointer
>does not say anything about the object it points to,
>So, __builtin_object_size can not directly use the type of the pointee
>to decide the size of
+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
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 the leela change. My recollection
was that the f-m-o work also picked up that case. But if
On Tue, Aug 01, 2023 at 03:20:33PM -0400, Drew Ross via Gcc-patches wrote:
> Canonicalizes (signed x << c) >> c into the lowest
> precision(type) - c bits of x IF those bits have a mode precision or a
> precision of 1. Also combines this rule with (unsigned x << c) >> c -> x &
> ((unsigned)-1 >>
> On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
>> On 2023-07-31 12:47, Qing Zhao wrote:
>>> Hi, Sid and Jakub,
>>>
>>> I have a question in the following source portion of the routine
>>> “addr_object_size” of
On Fri, Jul 28, 2023 at 06:03:33PM +, Joseph Myers wrote:
> You could e.g. have a table up to 10^(N-1) for some N, and 10^N, 10^2N
> etc. up to 10^6144 (or rather up to 10^6111, which can then be multiplied
> by a 34-digit integer significand), so that only one multiplication is
> needed to
Thank you for your effort.
I had evaluated only in intrate tests.
I am glad to see the same result on Leela.
On Tue, Aug 1, 2023 at 11:14 PM Vineet Gupta wrote:
>
>
> On 7/25/23 20:31, Jeff Law via Gcc-patches wrote:
> >
> >
> > On 7/25/23 05:24, Jivan Hakobyan wrote:
> >> Hi.
> >>
> >> I
When using -mcmodel=medium, large data objects larger than the
-mlarge-data-threshold threshold are placed into large data sections
(.lrodata, .ldata, .lbss and some variants). GNU ld and ld.lld 17 place
.l* sections into separate output sections. If small and medium code
model object files are
Hi Stam,
On Tue, 1 Aug 2023 at 19:22, Stamatis Markianos-Wright via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi all,
>
> The unsigned variants of the vcaddq_m operation are not needed within the
> compiler, as the assembly output of the signed and unsigned versions of the
> ops is
Canonicalizes (signed x << c) >> c into the lowest
precision(type) - c bits of x IF those bits have a mode precision or a
precision of 1. Also combines this rule with (unsigned x << c) >> c -> x &
((unsigned)-1 >> c) to prevent duplicate pattern. Tested successfully on
x86_64 and x86 targets.
On 6/30/23 2:26 PM, Pat Haugen via Gcc-patches wrote:
Updated from prior version to address latest review comment (simplify
umod3).
Disable generation of scalar modulo instructions.
It was recently discovered that the scalar modulo instructions can suffer
noticeable performance issues for
Canonicalizes (signed x << c) >> c into the lowest
precision(type) - c bits of x IF those bits have a mode precision or a
precision of 1. Also combines this rule with (unsigned x << c) >> c -> x &
((unsigned)-1 >> c) to prevent duplicate pattern. Tested successfully on
x86_64 and x86 targets.
Hi Jeff,
As discussed this morning, I'm sending over dumps for the optim of DF
const -0.0 (PR/110748) [1]
For rv64gc_zbs build, IRA is undoing the split which eventually leads to
ICE in final pass.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748#c15
void znd(double *d) { *d =
On 7/25/23 20:31, Jeff Law via Gcc-patches wrote:
On 7/25/23 05:24, Jivan Hakobyan wrote:
Hi.
I re-run the benchmarks and hopefully got the same profit.
I also compared the leela's code and figured out the reason.
Actually, my and Manolis's patches do the same thing. The difference
is
The IBM Z ELF ABI mandates every symbol to reside on a 2 byte boundary
in order to be able to use the larl instruction. However, in some
situations it is difficult to enforce this, e.g. for common linker
scripts as used in the Linux kernel. This patch introduces the
-munaligned-symbols option.
I'm afraid I don't understand this part of the code well, and I've really been
away from GCC work for years, and I'm not sure what tests should be run to
verify that this is working, so I don't feel comfortable approving it by
myself. It looks right though.
On Tue, Aug 1, 2023, at 1:55 AM,
Am Dienstag, dem 01.08.2023 um 15:54 + schrieb Michael Matz:
> Hello,
>
> On Mon, 31 Jul 2023, Martin Uecker wrote:
>
> > > Say you have a loop like so:
> > >
> > > _Atomic T obj;
> > > ...
> > > T expected1, expected2, newval;
> > > newval = ...;
> > > expected1 = ...;
> > > do {
> > >
This patch updates the support for the BPF CO-RE builtins
__builtin_preserve_access_index and __builtin_preserve_field_info,
and adds support for the CO-RE builtins __builtin_btf_type_id,
__builtin_preserve_type_info and __builtin_preserve_enum_value.
These CO-RE relocations are now converted to
This patch adds tests for the following builtins:
__builtin_preserve_enum_value
__builtin_btf_type_id
__builtin_preserve_type_info
---
.../gcc.target/bpf/core-builtin-enumvalue.c | 52 +
.../bpf/core-builtin-enumvalue_errors.c | 22
Hi everyone,
This patch series implements all the BPF CO-RE builtins.
It improves the support for __builtin_preserve_access_index and
__builtin_preserve_field_info, but also introduces the support for
__builtin_btf_type_id, __builtin_btf_preserve_type_info and
__builtin_preserve_enum_value.
GCC maintainers:
Ver 2: Re-worked the test vec-cmpne.c to create a compile only test
verify the instruction generation and a runnable test to verify the
built-in functionality. Retested the patch on Power 8 LE/BE, Power 9LE/BE and
Power 10 LE with no regressions.
The following patch cleans
Kewen:
On Mon, 2023-07-31 at 14:53 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/7/28 23:00, Carl Love wrote:
> > GCC maintainers:
> >
> > The following patch cleans up the definition for the
> > __builtin_altivec_vcmpnet. The current implementation implies that
> > the
>
>
On Thu, 27 Jul 2023, Ken Matsui via Gcc-patches wrote:
> This patch uses _GLIBCXX_HAS_BUILTIN_TRAIT macro instead of
> __has_builtin in the type_traits header. This macro supports to toggle
> the use of built-in traits in the type_traits header through
> _GLIBCXX_NO_BUILTIN_TRAITS macro, without
Hi all,
The unsigned variants of the vcaddq_m operation are not needed within the
compiler, as the assembly output of the signed and unsigned versions of the
ops is identical: with a `.i` suffix (as opposed to separate `.s` and `.u`
suffixes).
Tested with baremetal arm-none-eabi on Arm's
On Tue, 2023-08-01 at 09:52 -0400, Eric Feng wrote:
> Hi all,
>
> This patch adds a hook to the end of ana::on_finish_translation_unit
> which calls relevant stashing-related callbacks registered during
> plugin
> initialization. This feature is used to stash named types and global
> variables
On Tue, 1 Aug 2023, Michael Matz via Gcc-patches wrote:
> Only because cmpxchg is defined in terms of memcpy/memcmp. If it were
> defined in terms of the == operator (obviously applied recursively
> member-wise for structs) and simple-assignment that wouldn't be a problem.
It also wouldn't
Thanks Richard,
I've gone through the write access process and committed this.
On 7/31/2023 10:56 AM, Richard Sandiford wrote:
Richard Ball writes:
Add POLY_INT_CST support to code within
fold_ctor_reference. This code previously
only supported INTEGER_CST which caused a
bug when using
On 7/25/23 09:40, Richard Biener wrote:
The following removes the code checking whether a noop copy
is between something involved in the return sequence composed
of a SET and USE. Instead of checking for this special-case
the following makes us only ever remove noop copies between
pseudos -
Hello,
On Mon, 31 Jul 2023, Martin Uecker wrote:
> > Say you have a loop like so:
> >
> > _Atomic T obj;
> > ...
> > T expected1, expected2, newval;
> > newval = ...;
> > expected1 = ...;
> > do {
> > expected2 = expected1;
> > if (atomic_compare_exchange_weak(, , newval);
> > break;
>
Hi Thomas,
this is v2 of the patch for implementing the OpenACC 2.7 addition of
default(none|present) support for data constructs.
Instead of propagating an additional 'oacc_default_kind' for OpenACC,
this patch does it in a more complete way: it directly propagates the
gimplify_omp_ctx* pointer
On Mon, 31 Jul 2023, Lewis Hyatt via Gcc-patches wrote:
> I added some additional testcases from the PR for x86. The other targets
> that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390)
> already had tests verifying that the pragma sets macros as expected; here I
> have added
Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao:
>
> > On Aug 1, 2023, at 3:51 AM, Martin Uecker via Gcc-patches
> > wrote:
> >
> > > Hi Martin,
> > > Just wondering if it'd be a good idea perhaps to warn if alloc size is
> > > not a multiple of TYPE_SIZE_UNIT instead of
Hi,
this patch adds vector average patterns
op[0] = (narrow) ((wide) op[1] + (wide) op[2]) >> 1;
op[0] = (narrow) ((wide) op[1] + (wide) op[2] + 1) >> 1;
If there is no direct support, the vectorizer can synthesize the patterns
but, presumably due to lack of narrowing operation support, won't
Sponsored by Richard Sandiford
ChangeLog:
* MAINTAINERS: Add myself.
###
diff --git a/MAINTAINERS b/MAINTAINERS
index 49aa6bae73b..a8bb43f50c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -332,6 +332,7 @@ David Ayers
Hi all,
This patch adds a hook to the end of ana::on_finish_translation_unit
which calls relevant stashing-related callbacks registered during plugin
initialization. This feature is used to stash named types and global
variables for a CPython analyzer plugin [PR107646].
Bootstrapped and tested
Hi Joern,
thanks, I believe this will help with testing.
> +proc check_effective_target_riscv_v { } {
> +return [check_no_compiler_messages riscv_ext_v assembly {
> + #ifndef __riscv_v
> + #error "Not __riscv_v"
> + #endif
> +}]
> +}
This can be replaced by riscv_vector
Committed as obvious. An insn emitted by avr specific RTL optimization
pass missed setting of its JUMP_LABEL.
Johann
target/110220: Set JUMP_LABEL and LABEL_NUSES of new branch insn
generated by
target specific RTL optimization pass .avr-casesi.
gcc/
PR
Hi,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Richard Biener writes:
>
>> On Mon, 24 Jul 2023, Jiufu Guo wrote:
>>
>>>
>>> Hi Martin,
>>>
>>> Not sure about your current option about re-using the ipa-sra code
>>> in the light-expander-sra. And if anything I could input please
>>> let me
Jeff Law via Gcc-patches writes:
> On 7/19/23 04:11, Xiao Zeng wrote:
>> This patch completes the recognition of the basic semantics
>> defined in the spec, namely:
>>
>> Conditional zero, if condition is equal to zero
>>rd = (rs2 == 0) ? 0 : rs1
>> Conditional zero, if condition is non zero
Hi,
This patch fixes update after constant peeling in profilogue. We now reached 0
profile
update bugs on tramp3d vectorizaiton and also on quite few testcases, so I am
enabling the
testuiste checks so we do not regress again.
Bootstrapped/regtested x86_64, comitted.
Honza
gcc/ChangeLog:
Hi Richard,
This is a quick fix to the several ICEs. It seems even STMT_VINFO_LIVE_P is
true, some reduct stmts still don't have REDUC_DEF. So I change the check to
STMT_VINFO_REDUC_DEF.
Is it OK for trunk?
---
Fix the ICEs on empty reduction define. Even STMT_VINFO_LIVE_P is true, some
Richard Sandiford writes:
> Richard Biener via Gcc-patches writes:
>> The following makes sure to limit the shift operand when vectorizing
>> (short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
>> operand otherwise invokes undefined behavior. When we determine
>> whether we can
On Tue, Aug 01, 2023 at 01:52:16PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 1 Aug 2023 at 05:20, Jeff Law wrote:
> >
> >
> >
> > On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> > > Gcc-patches wrote:
> > >>
> >
The @novell.com one has been out of use for quite some time.
ChangeLog:
* MAINTAINERS: Correct my email address.
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -344,7 +344,7 @@ Andrew Bennett
Daniel Berlin
Pat Bernardi
Richard Biener via Gcc-patches writes:
> The following makes sure to limit the shift operand when vectorizing
> (short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
> operand otherwise invokes undefined behavior. When we determine
> whether we can demote the operand we know we at
Fix spelling mistakes introduced by my previous patch in this area.
Committed as obvious.
2023-08-01 Christophe Lyon
gcc/
* doc/sourcebuild.texi (arm_v8_1m_main_cde_mve_fp): Fix spelling.
---
gcc/doc/sourcebuild.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Tue, 1 Aug 2023 at 05:20, Jeff Law wrote:
>
>
>
> On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> >>
> >> Comparisons between memory and constants might be done in a smaller mode
> >>
Ping!
Forwarded Message
Subject: [PING^2] [PATCH 3/4] ree: Improve functionality of ree pass for rs6000
target.
Date: Tue, 18 Jul 2023 13:31:27 +0530
From: Ajit Agarwal
To: gcc-patches
CC: Jeff Law , Richard Biener
, Segher Boessenkool ,
Peter Bergner
Ping^2.
Please
Ping!
Forwarded Message
Subject: [PING^2] PATCH v5 4/4] ree: Improve ree pass for rs6000 target using
defined ABI interfaces.
Date: Tue, 18 Jul 2023 13:28:08 +0530
From: Ajit Agarwal
To: gcc-patches
CC: Jeff Law , Richard Biener
, Segher Boessenkool ,
Peter Bergner
Ping!
Forwarded Message
Subject: [PATCH v8] tree-ssa-sink: Improve code sinking pass.
Date: Tue, 18 Jul 2023 19:03:37 +0530
From: Ajit Agarwal
To: gcc-patches
CC: Richard Biener , Jeff Law
, Segher Boessenkool , Peter
Bergner
Hello All:
This patch improves code sinking
From: Yannick Moy
Subprograms with these Skip(_Flow_And)_Proof annotations should not be
inlined in GNATprove, as we want to skip part of the analysis for their
body.
gcc/ada/
* inline.adb (Can_Be_Inlined_In_GNATprove_Mode): Check for
Skip_Proof and Skip_Flow_And_Proof
From: Steve Baird
In some cases, a bugbox is generated when compiling an example
that references X'Image, where X is a constrained object of a
discriminated protected type.
gcc/ada/
* sem_ch3.adb (Constrain_Corresponding_Record): When copying
information from the unconstrained
From: Yannick Moy
When calling GNAT with -gnatRj to generate JSON output for the
data representation of types and objects, it could happen that
numbers are printed in the Ada syntax for hexadecimal numbers, which
leads to an invalid JSON file being generated. Now fixed both for
the JSON output
From: Steve Baird
If the discriminants of an immutably limited record type have defaults, then
it is safe to assume that a discriminant of an object of this type will never
change once it is initialized. In some cases, this means that the default
discriminant values can be treated like a
From: Léo Creuse
The tree traversal for decision SCO emission did not recurse in the
iterator specification or loop parameter specification of quantified
expressions, resulting in missing coverage obligations for nested
decisions. This change fixes this by traversing all the attributes
of
From: Yannick Moy
Using -gnatRj to generate data representation in JSON format could
lead to an ill-formed output or an assertion failure. Now fixed.
gcc/ada/
* repinfo.adb (List_Common_Type_Info): Fix output when alignment
is not statically known, and fix assertion when
From: Pascal Obry
The output generated by a call to Some_Derived_Composite_Type'Put_Image
(in Ada2022 code) is incomplete in some cases, notably for a type derived
from a container type (i.e., from the Set/Map/List/Vector type declared in
an instance of one of Ada's predefined container
From: Bob Duff
Get_Field_Value and Set_Field_Value now check that the Nkind or Ekind is
correct. However, the checks are partially disabled, because they
sometimes fail.
gcc/ada/
* atree.adb (Field_Present): New function to detect whether or not
a given field is present in a
Committed, thanks a lof, Robin and Kito, very appreciative for the explanation
and comments from the expert's perspective.
Pan
-Original Message-
From: Kito Cheng
Sent: Tuesday, August 1, 2023 3:51 PM
To: Li, Pan2
Cc: Robin Dapp ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai;
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, August 1, 2023 3:22 PM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support RVV VFSUB and VFRSUB rounding mode
intrinsic API
LGTM
Am Dienstag, dem 01.08.2023 um 02:11 +0530 schrieb Prathamesh Kulkarni:
> On Fri, 21 Jul 2023 at 16:52, Martin Uecker via Gcc-patches
> wrote:
> >
> >
> >
> > This patch adds a warning for allocations with insufficient size
> > based on the "alloc_size" attribute and the type of the pointer
>
Hi Pan:
Thanks for your effort on this, this is LGTM and OK for trunk.
Hi Robin:
Thanks for your review on this stuff, this set of intrinsic functions
is complicated and might be controversial since the whole floating
point rounding mode is…complicated, and people might have different
tastes
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-01 14:48
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFSUB and VFRSUB rounding mode
intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for
Hi,
Richard Biener writes:
> On Mon, 24 Jul 2023, Jiufu Guo wrote:
>
>>
>> Hi Martin,
>>
>> Not sure about your current option about re-using the ipa-sra code
>> in the light-expander-sra. And if anything I could input please
>> let me know.
>>
>> And I'm thinking about the difference
From: Pan Li
This patch would like to support the rounding mode API for both the
VFSUB and VFRSUB as below samples.
* __riscv_vfsub_vv_f32m1_rm
* __riscv_vfsub_vv_f32m1_rm_m
* __riscv_vfsub_vf_f32m1_rm
* __riscv_vfsub_vf_f32m1_rm_m
* __riscv_vfrsub_vf_f32m1_rm
* __riscv_vfrsub_vf_f32m1_rm_m
>>> I'm not against continuing with the more well-known approach for now
>>> but we should keep in mind that might still be potential for improvement.
>
> No. I don't think it's faster.
I did a quick check on my x86 laptop and it's roughly 25% faster there.
That's consistent with the literature.
From: Ju-Zhe Zhong
Hi, Richard and Richi.
Base on the suggestions from Richard:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
This patch choose (1) approach that Richard provided, meaning:
RVV implements cond_* optabs as expanders. RVV therefore supports
both IFN_COND_ADD
On 7/29/23 03:13, Xiao Zeng wrote:
This patch recognizes Zicond patterns when the select pattern
with condition eq or neq to 0 (using eq as an example), namely:
1 rd = (rs2 == 0) ? non-imm : 0
2 rd = (rs2 == 0) ? non-imm : non-imm
3 rd = (rs2 == 0) ? reg : non-imm
4 rd = (rs2 == 0) ? reg :
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, August 1, 2023 1:49 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; Kirill Yukhin
>
> Subject: [PATCH] x86: fold two of vec_dupv2df's alternatives
>
> By using Yvm in the source, both can be expressed in one.
>
> gcc/
>
90 matches
Mail list logo
