> +enum __RISCV_VXRM {
> + __RISCV_VXRM_RNU = 0,
> + __RISCV_VXRM_RNE = 1,
> + __RISCV_VXRM_RDN = 2,
> + __RISCV_VXRM_ROD = 3,
> +};
> +
> __extension__ extern __inline unsigned long
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> vread_csr(enum RVV_CSR csr)
We have
On Wed, Jul 12, 2023 at 6:09 PM Andrew Pinski via Gcc-patches
wrote:
>
> This fixes part of PR 110293, for the outer comparison case
> being `!=` or `==`. In turn PR 110539 is able to be optimized
> again as the if statement for `(a&1) == ((a & 1) != 0)` gets optimized
> to `false` early enough
When trying to bootstrap current trunk on macOS 14.0 beta 3 with Xcode
15 beta 4, the build failed running mklink in stage 2:
unset CC ; m2/boot-bin/mklink -s --langc++ --exit --name m2/mc-boot/main.cc
/vol/gcc/src/hg/master/darwin/gcc/m2/init/mcinit
dyld[55825]: Library not loaded:
Hmmm, anyway, I guess it's not worth spending any more of your time,
LGTM for v3 :)
On Thu, Jul 13, 2023 at 5:10 PM Li, Pan2 via Gcc-patches
wrote:
>
> It can pass the selftest with below diff based on v3, but got ICE when build
> newlib.
>
>
Factorize vcaddq, vhcaddq so that they use the same parameterized
names.
To be able to use the same patterns, we add a suffix to vcaddq.
Note that vcadd uses UNSPEC_VCADDxx for builtins without predication,
and VCADDQ_ROTxx_M_x (that is, not starting with "UNSPEC_"). The
UNPEC_* names are also
Hi,
the recent changes that allowed multi-step conversions for
"non-packing/unpacking", i.e. modifier == NONE targets included
promoting to-float and demoting to-int variants. This patch
adds demoting to-float and promoting to-int handling.
Bootstrapped and regtested on x86 and aarch64.
A
On Thu, Jul 13, 2023 at 12:31 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> the recent changes that allowed multi-step conversions for
> "non-packing/unpacking", i.e. modifier == NONE targets included
> promoting to-float and demoting to-int variants. This patch
> adds demoting to-float and
On Thu, 13 Jul 2023, Tamar Christina wrote:
> > e7ac2b5f3db55de3dbbab7bd2bfe08388f4ec533..cab82d7960e5be517bba2
> > 621f7f4
> > > 888e7bf3c295 100644
> > > --- a/gcc/cfgloop.h
> > > +++ b/gcc/cfgloop.h
> > > @@ -272,6 +272,14 @@ public:
> > > the basic-block from being collected but its
> Can you add testcases? Also the current restriction is because
> the variants you add are not always correct and I don't see any
> checks that the intermediate type doesn't lose significant bits?
The testcases I wanted to add with a follow-up RISC-V patch but
I can also try an aarch64 one.
So
On 7/12/23 07:05, senthilkumar.selva...@microchip.com wrote:
Hi,
I've been spending some (spare) time trying to get LRA working
for the avr target.
Thank you for addressing this problem.
The code you changing is very sensitive and was a source of multiple PRs
in the past. But I
Implement vcmlaq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcmlaq, vcmlaq_rot90)
(vcmlaq_rot180, vcmlaq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcmlaq, vcmlaq_rot90)
This tests currently expect a directive containing .fpu fpv5-sp-d16
and thus may fail if the test is executed for instance with
-march=armv8.1-m.main+mve.fp+fp.dp
This patch accepts either fpv5-sp-d16 or fpv5-d16 to avoid the failure.
2023-06-28 Christophe Lyon
gcc/testsuite/
If GCC is configured with the default (soft) -mfloat-abi, and we don't
override the target_board test flags appropriately,
gcc.target/arm/mve/general-c/nomve_fp_1.c fails for lack of
-mfloat-abi=softfp or -mfloat-abi=hard, because it doesn't use
dg-add-options arm_v8_1m_mve (on purpose, see
Implement vcaddq, vhcaddq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcaddq_rot90)
(vcaddq_rot270, vhcaddq_rot90, vhcaddq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcaddq_rot90)
Implement vcmulq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcmulq, vcmulq_rot90)
(vcmulq_rot180, vcmulq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcmulq, vcmulq_rot90)
On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote:
>
> On 7/3/23 1:31 PM, Richard Biener wrote:
> > On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
> >>
> >> On 6/29/23 6:55 PM, Richard Biener wrote:
> >>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod
> >>> wrote:
>
>
>
>
Sure and committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, July 13, 2023 5:19 PM
To: Li, Pan2
Cc: Jeff Law ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; rdapp@gmail.com; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: Refactor riscv mode after
On 2023/6/16 5:13 PM, Thomas Schwinge wrote:
> OK with one small change, please -- unless there's a reason for doing it
> this way:
>
>> --- a/gcc/fortran/trans-openmp.cc
>> +++ b/gcc/fortran/trans-openmp.cc
>> @@ -4677,6 +4677,12 @@ gfc_trans_oacc_construct (gfc_code *code)
>> break;
>>
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Hi All,
>
> This patch splits off the vectorizer's understanding of the main loop exit off
> from the normal loop infrastructure.
>
> Essentially we're relaxing the use of single_exit() in the vectorizer as we
> will
> no longer have a single
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Hi All,
>
> For early break vectorization we have to update niters analysis to record and
> analyze all exits of the loop, and so all conds.
>
> The niters of the loop is still determined by the main/natural exit of the
> loop
> as this is the O(n)
On 7/3/23 1:31 PM, Richard Biener wrote:
On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
On 6/29/23 6:55 PM, Richard Biener wrote:
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
From: Richard Biener
Date: Tuesday, June 27, 2023 at 12:58 PM
To: Tejas Belagod
Cc:
Factorize vcmulq builtins so that they use parameterized names.
We can merged them with vcadd.
2023-07-13 Christophe Lyon
gcc/:
* config/arm/arm_mve_builtins.def (vcmulq_rot90_f)
(vcmulq_rot270_f, vcmulq_rot180_f, vcmulq_f): Add "_f" suffix.
*
Factorize vcmlaq builtins so that they use parameterized names.
2023-17-13 Christophe Lyon
gcc/
* config/arm/arm_mve_builtins.def (vcmlaq_rot90_f)
(vcmlaq_rot270_f, vcmlaq_rot180_f, vcmlaq_f): Add "_f" suffix.
* config/arm/iterators.md (MVE_VCMLAQ_M): New.
On Thu, 13 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> Previous patch we support COND_LEN_* binary operations. However, we didn't
> support COND_LEN_* ternary.
>
> Now, this patch support COND_LEN_* ternary. Consider this following case:
>
>
Enable COND_LEN_FMA auto-vectorization for floating-point FMA
auto-vectorization **NO** ffast-math.
Since the middle-end support has been approved and I will merge it after I
finished bootstrap && regression on X86.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624395.html
Now, it's time
Could you tell me how to add the comment?
I am not familiar with link/binutils stuff.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-13 19:40
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Enable COND_LEN_FMA
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 13, 2023 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 8/19]middle-end: updated niters analysis to handle
> multiple exits.
>
> On Wed, 28 Jun 2023, Tamar
Hi Juzhe,
thanks, no complaints from my side apart from one:
> +/* { dg-additional-options "-mcmodel=medany" } */
Please add a comment why we need this.
Regards
Robin
I have no ideal.
This testcase cause link ICE:
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_run-7.c (test
for excess errors)
Excess errors:
scatter_store_run-7.c:(.text.startup+0xc8e): relocation truncated to fit:
R_RISCV_GPREL_I against `.LANCHOR1'
only LMUL = M8 will cause
> e7ac2b5f3db55de3dbbab7bd2bfe08388f4ec533..cab82d7960e5be517bba2
> 621f7f4
> > 888e7bf3c295 100644
> > --- a/gcc/cfgloop.h
> > +++ b/gcc/cfgloop.h
> > @@ -272,6 +272,14 @@ public:
> > the basic-block from being collected but its index can still be
> > reused. */
> >basic_block
On Thu, Jul 13, 2023 at 2:19 PM Robin Dapp wrote:
>
> > Can you add testcases? Also the current restriction is because
> > the variants you add are not always correct and I don't see any
> > checks that the intermediate type doesn't lose significant bits?
>
> The testcases I wanted to add with a
Hi Carl,
on 2023/7/12 02:06, Carl Love wrote:
> GCC maintainers:
>
> Ver 4, Removed extra space in subject line. Added comment to commit
> log comments about new __SET_FPSCR_RN_RETURNS_FPSCR__ define. Changed
> Added to Add and Renamed to Rename in ChangeLog. Updated define_expand
>
Oh, sorry for that, thank you very much! XD
-Original Messages-
From: "Kito Cheng"
Sent Time: 2023-07-13 15:24:45 (Thursday)
To: "Robin Dapp"
Cc: chenyix...@iscas.ac.cn, gcc-patches@gcc.gnu.org, and...@sifive.com,
shiyul...@iscas.ac.cn, oriachi...@gmail.com, shi...@iscas.ac.cn,
LGTM, thanks, just like other zc* patches, I would like to defer this
until the binutils part landed :)
On Wed, Jun 7, 2023 at 1:54 PM Fei Gao wrote:
>
> From: Die Li
>
> Signed-off-by: Die Li
> Co-Authored-By: Fei Gao
>
> gcc/ChangeLog:
>
> * config/riscv/peephole.md: New pattern.
>
On Thu, Jul 13, 2023 at 2:32 PM Richard Biener wrote:
>
> On Thu, 13 Jul 2023, Hongtao Liu wrote:
>
> > On Thu, Jul 13, 2023 at 10:47?AM Hongtao Liu wrote:
> > >
> > > On Wed, Jul 12, 2023 at 9:37?PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > The PRs ask for optimizing of
> > >
Final procedure pointer expression is generated in gfc_build_final_call
and only used in get_final_proc_ref. Move the generation there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
final_expr. Pass down expr to get_final_proc_ref and move
Reuse twice the same final procedure pointer expression instead of
translating it twice.
Final procedure pointer expressions were translated twice, once for the
final procedure call, and once for the check for non-nullness (if
applicable).
gcc/fortran/ChangeLog:
* trans.cc
Hello,
the following patches are abot PR110618, a PR similar to PR92178 from which
it is cloned. Both are about a problem of dedendencies between arguments,
when one of them is associated to an allocatable intent(out) dummy, and thus
deallocated in the process of argument association.
PR110618
The same scalar descriptor generation code is present twice, in the
case of derived type entities, and in the case of polymorphic
non-coarray entities. Factor it in preparation for a future third case
that will also need the same code for scalar descriptor generation.
gcc/fortran/ChangeLog:
Move cleanup code for the data descriptor after the finalization code
as it makes more sense to have it after.
Other cleanup blocks should be empty (element size and final pointer
are just data references), but add them by the way, just in case.
gcc/fortran/ChangeLog:
* trans.cc
get_var_descr get passed as argument both expr and expr->ts.
Remove the type argument which can be retrieved from the other
argument.
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): Remove argument ts. Use var->ts
instead.
(gfc_add_finalizer_call): Update caller.
---
From: Kong Lingling
gcc/ChangeLog
* common/config/i386/cpuinfo.h (get_available_features): Detect
avxvnniint16.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVXVNNIINT16_SET): New.
(OPTION_MASK_ISA2_AVXVNNIINT16_UNSET): Ditto.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect SHA512.
* common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SHA512_SET,
OPTION_MASK_ISA2_SHA512_UNSET): New.
(OPTION_MASK_ISA2_AVX_UNSET): Add SHA512.
On Wed, 12 Jul 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > The PRs ask for optimizing of
> >
> > _1 = BIT_FIELD_REF ;
> > result_4 = BIT_INSERT_EXPR ;
> >
> > to a vector permutation. The following implements this as
> > match.pd pattern, improving code generation on x86_64.
Those enum values have been defined via `#pragma riscv intrinsic "vector"` :)
https://github.com/gcc-mirror/gcc/commit/01d62e9b6c3e9fd3132f1616843103ccf81778ed
On Thu, Jul 13, 2023 at 2:55 PM Robin Dapp via Gcc-patches
wrote:
>
> > +enum __RISCV_VXRM {
> > + __RISCV_VXRM_RNU = 0,
> > +
oh, I know why you failed on that, you need to put it within the
function, not global static, function static variable will construct
when first invoked rather than construct at program start.
Could you try to apply my diff in the last mail and try again?
On Thu, Jul 13, 2023 at 3:29 PM Li, Pan2
Hi,
This tiny patch add a check for extension starts with 'z' or 's' in `-march`
option. Currently this unknown extension will be passed to the assembler, which
then reports an error. With this patch, the compiler will throw a compilation
error if the extension starts with 'z' or 's' is not a
I was thinking does it possible to using peephole2 to optimize this
case, but I realized their is several barrier, like stack tie and
note...so it seems hard to just leverage peephole2.
And the patch is LGTM, only a few minor coding format issues, but you
don't need to send new patch, I can fix
Hi, Richard.
>> either before or after white-space seems broken.
I use clang-format with the format in gcc/contrib/format.
I manually adjust it, could you take a look to see whether the format issue is
still there?
I have address all your comments with V2 patch:
From: Ju-Zhe Zhong
Hi, Richard and Richi.
Previous patch we support COND_LEN_* binary operations. However, we didn't
support COND_LEN_* ternary.
Now, this patch support COND_LEN_* ternary. Consider this following case:
#define TEST_TYPE(TYPE)
Add the possibility to provide a pre-evaluated class container argument
to gfc_add_finalizer to avoid repeatedly evaluating data reference
expressions in the generated code.
PR fortran/110618
gcc/fortran/ChangeLog:
* trans.h (gfc_add_finalizer_call): Add class container
Hi Carl,
on 2023/7/8 04:18, Carl Love wrote:
>
> GCC maintainers:
>
> Version 3, added code to altivec_resolve_overloaded_builtin so the
> correct instruction is selected for the size of the second argument.
> This restores the instruction counts to the original values where the
> correct
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect SM3.
* common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SM3_SET,
OPTION_MASK_ISA2_SM3_UNSET): New.
(OPTION_MASK_ISA2_AVX_UNSET): Add SM3.
(ix86_handle_option): Handle
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detech SM4.
* common/config/i386/i386-common.cc (OPTION_MASK_ISA2_SM4_SET,
OPTION_MASK_ISA2_SM4_UNSET): New.
(OPTION_MASK_ISA2_AVX_UNSET): Add SM4.
(ix86_handle_option): Handle
Hi all,
These four patches aimed to add Intel Arrow Lake/Lunar Lake
instructions, including AVX-VNNI-INT16, SM3, SHA512 and SM4.
The information is based on newly released
Intel Architecture Instruction Set Extensions and Future Features.
The document comes following:
Hmmm? I didn't get that error on selftest?
my diff with your v2:
$ git diff
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 12655f7fdc65..466e1aed91c7 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -8058,8 +8058,9 @@ asm_insn_p (rtx_insn *insn)
From: Yanzhang Wang
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_save_reg_p): Save ra for leaf
when enabling -mno-omit-leaf-frame-pointer
(riscv_option_override): Override omit-frame-pointer.
(riscv_frame_pointer_required): Save s0 for non-leaf function
On Thu, 13 Jul 2023, Hongtao Liu wrote:
> On Thu, Jul 13, 2023 at 10:47?AM Hongtao Liu wrote:
> >
> > On Wed, Jul 12, 2023 at 9:37?PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > The PRs ask for optimizing of
> > >
> > > _1 = BIT_FIELD_REF ;
> > > result_4 = BIT_INSERT_EXPR ;
> > >
From: XYenChi
Noticed that the rvv-intrinsic-doc updated the __RISCV_VXRM.
gcc/ChangeLog:Add __RISCV_VXRM enum to riscv_vector.h
2023-07-13 XYenChi
* config/riscv/riscv_vector.h (enum __RISCV_VXRM):Add an enum
__RISCV_VXRM to help express the rounding modes.
---
On Thu, Jul 13, 2023 at 1:30 AM 钟居哲 wrote:
>
> I notice vectorizable_call in Loop Vectorizer.
> It's vectorizing CALL function for example like fmax/fmin.
> From my understanding, we dont have RVV instruction for fmax/fmin?
There's things like .POPCOUNT which we can vectorize, but sure, it
The following makes sure that FP x > y ? x : y style max/min operations
are if-converted at the GIMPLE level. While we can neither match
it to MAX_EXPR nor .FMAX as both have different semantics with IEEE
than the ternary ?: operation we can make sure to maintain this form
as a COND_EXPR so
Thanks Kito for review. Sorry didn't involve the code result in self test error
in PATCH v3, but it can be reproduced with below diff based on PATCH v3. Let me
know if I didn't get the point of your comments.
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index
On Thu, 13 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> Previous patch we support COND_LEN_* binary operations. However, we didn't
> support COND_LEN_* ternary.
>
> Now, this patch support COND_LEN_* ternary. Consider this following case:
>
>
Thanks for review. I uploaded version V2, which addresses Kito's comments,
along with two changes. The first is to reduce repeated errors, which are
currently
reported at least twice. The second is to report as many mistakes as possible.
V2
Sure thing, get you point now, will have a try and send v4 if everything goes
well.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, July 13, 2023 3:35 PM
To: Li, Pan2
Cc: Jeff Law ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; rdapp@gmail.com; Wang, Yanzhang
Subject:
gcc/fortran/ChangeLog:
* trans.cc (get_final_proc_ref): New function.
(gfc_build_final_call): Outline the pointer evaluation code
to get_final_proc_ref.
---
gcc/fortran/trans.cc | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git
gfc_add_finalizer_call creates one expression which is only used
by the get_final_proc_ref function. Move the expression generation
there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
elem_size. Pass expression to get_elem_size and move the
The variable has_finalizer is only used in one place, inline its
definition there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Inline definition of
variable has_finalizer. Merge nested conditions.
---
gcc/fortran/trans.cc | 16 +++-
1 file changed, 7
It can pass the selftest with below diff based on v3, but got ICE when build
newlib.
/home/pli/repos/gcc/222/riscv-gnu-toolchain/newlib/newlib/libc/time/../time/strftime.c:1426:1:
internal compiler error: in reg_overlap_mentioned_p, at rtlanal.cc:1928
1426 | }
| ^
0x87241f
On Wed, 12 Jul 2023 at 21:42, Ken Matsui wrote:
>
> On Wed, Jul 12, 2023 at 3:01 AM Jonathan Wakely wrote:
> >
> > On Mon, 10 Jul 2023 at 06:51, Ken Matsui via Libstdc++
> > wrote:
> > >
> > > Hi,
> > >
> > > Here is the benchmark result for is_pointer:
> > >
> > >
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): New function.
(gfc_build_final_call): Outline the data reference descriptor
evaluation code to get_var_descr.
---
gcc/fortran/trans.cc | 149 ---
1 file changed, 83 insertions(+),
gcc/fortran/ChangeLog:
* trans.cc (get_elem_size): New function.
(gfc_build_final_call): Outline the element size evaluation
to get_elem_size.
---
gcc/fortran/trans.cc | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
Function gfc_build_final_call has been simplified, inline it.
gcc/fortran/ChangeLog:
* trans.cc (gfc_build_final_call): Inline...
(gfc_add_finalizer_call): ... to its one caller.
---
gcc/fortran/trans.cc | 66 +---
1 file changed, 25
gcc/fortran/ChangeLog:
* trans.cc (get_vptr): New function.
(gfc_add_finalizer_call): Move virtual table pointer evaluation
to get_vptr.
---
gcc/fortran/trans.cc | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git
Pass already evaluated class container argument from
gfc_conv_procedure_call down to gfc_add_finalizer_call through
gfc_deallocate_scalar_with_status and gfc_deallocate_with_status,
to avoid repeatedly evaluating the same data reference expressions
in the generated code.
PR fortran/110618
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
This fixes a crash when mangling an ADL-enabled call to a template-id
naming an unknown template (as per P0846R0).
PR c++/110524
gcc/cp/ChangeLog:
* mangle.cc
On 7/13/23 01:47, Richard Biener wrote:
On Thu, Jul 13, 2023 at 1:30 AM 钟居哲 wrote:
I notice vectorizable_call in Loop Vectorizer.
It's vectorizing CALL function for example like fmax/fmin.
From my understanding, we dont have RVV instruction for fmax/fmin?
There's things like .POPCOUNT
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Thursday, July 13, 2023 6:51 PM
To: Ju-Zhe Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] SSA MATH: Support COND_LEN_FMA for
From my understanding, we dont have RVV instruction for fmax/fmin?
>
> Unless I'm misunderstanding, we do. The ISA manual says
>
> === Vector Floating-Point MIN/MAX Instructions
>
> The vector floating-point `vfmin` and `vfmax` instructions have the
> same behavior as the
I didn’t try on local yet, but it sounds like …the code size might larger
than normal case?
juzhe.zh...@rivai.ai 於 2023年7月13日 週四，19:50寫道：
> Could you tell me how to add the comment?
> I am not familiar with link/binutils stuff.
>
> --
> juzhe.zh...@rivai.ai
>
>
>
On 7/12/23 17:30, 钟居哲 wrote:
I notice vectorizable_call in Loop Vectorizer.
It's vectorizing CALL function for example like fmax/fmin.
From my understanding, we dont have RVV instruction for fmax/fmin?
So for now, I don't need to support builtin call function vectorization
for RVV.
Am I
Currently the operations allowed for if conversion of a basic block with
multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
bb_ok_for_noce_convert_multiple_sets).
This commit allows more operations (arithmetic, compare, etc) to participate
in if conversion. The target's
This is an extension of what was done in PR106590.
Currently if a sequence generated in noce_convert_multiple_sets clobbers the
condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
(sequences that emit the comparison itself). Since this applies only from the
next iteration it
On Wed, Jul 12, 2023 at 5:14 PM Jeff Law wrote:
>
>
>
> On 7/12/23 03:12, Manolis Tsamis wrote:
> > On Mon, Jul 10, 2023 at 12:58 AM Hans-Peter Nilsson
> > wrote:
> >>
> >> On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote:
> >>
> >>> On Thu, 15 Jun 2023, Manolis Tsamis wrote:
> >>>
> This is a
No, I am just want to whether we have some CALL vectorization need len or mask
predication.
For example, Current GCC vectorization CALL onyl FMAX/FMIN/FMA/FNMA/FMS/FNMS
these CALL function
need length or mask predicate. I don't care about sin/cos/popcount...etc. We
just use full vector
Hi Martin,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Martin Jambor writes:
>
>> Hi,
>>
>> On Tue, May 30 2023, Richard Biener wrote:
>>> On Mon, 29 May 2023, Jiufu Guo wrote:
>>>
Hi,
Previously, I was investigating some struct parameters and returns related
PRs
noce_convert_multiple_sets has been introduced and extended over time to handle
if conversion for blocks with multiple sets. Currently this is focused on
register moves and rejects any sort of arithmetic operations.
This series is an extension to allow more sequences to take part in if
I resent this with just the change in the comment.
OK to merge?
Manolis
On Tue, Jul 4, 2023 at 5:32 PM Manolis Tsamis wrote:
>
> On Mon, Jul 3, 2023 at 12:12 PM Robin Dapp wrote:
> >
> > Hi Manolis,
> >
> > that looks like a nice enhancement of what's already possible. The concern
> > I had
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit b175b4887f928118af997f6d4d75097a64dcec5d
Author: Vladimir N. Makarov
Date: Thu Jul 13 10:42:17 2023 -0400
On Thu, 13 Jul 2023 07:01:26 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 7/13/23 01:47, Richard Biener wrote:
>> On Thu, Jul 13, 2023 at 1:30â¯AM éå±
å² wrote:
>>>
>>> I notice vectorizable_call in Loop Vectorizer.
>>> It's vectorizing CALL function for example like fmax/fmin.
>>>
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following
Yes. Not always fail.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-13 22:39
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; jeffreyalaw; kito.cheng; palmer; palmer
Subject: Re: Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization
I didn’t try on local yet, but it sounds
In this version I have made f-m-o able to also eliminate constant
moves in addition to the add constant instructions.
This increases the number of simplified/eliminated instructions and is
a good addition for RISC style ISAs where these are more common.
This has led to pr52146.c failing in x86,
> Is COND _LEN FMA ok for trunk? I can commit it without changing
> scatter store testcase fix.
>
> It makes no sense block cond Len fma support. The middle end support
> has already been merged.
Then just add a TODO or so that says e.g. "For some reason we exceed
the default code model's +-2
PR target/106966
gcc/ChangeLog:
* config/alpha/alpha.cc (alpha_emit_set_long_const):
Always use DImode when constructing long const.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr106966.c: New test.
Bootstrapped and regression tested by Matthias on alpha-linux-gnu.
Uros.
diff
On 7/13/23 08:20, Manolis Tsamis wrote:
I have sent a V3 which contains a number of fixes and improvements:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624439.html
I tested the new version rebased on master and the m68k issue did not reproduce.
I don't know what exactly fixed it; do
This patch resolves PR target/110588 to catch another case in combine
where the i386 backend should be generating a btl instruction. This adds
another define_insn_and_split to recognize the RTL representation for this
case.
I also noticed that two related define_insn_and_split weren't using the
On Wed, 28 Jun 2023, Patrick Palka wrote:
> On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
> >
> > On 6/23/23 12:23, Patrick Palka wrote:
> > > On Fri, 23 Jun 2023, Jason Merrill wrote:
> > >
> > >> On 6/21/23 13:19, Patrick Palka wrote:
> > >>> When stepping through the variable/alias
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Adding proper maintainers.
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, June 28, 2023 2:46 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Marcus Shawcroft ; Kyrylo Tkachov
> > ; Richard
This is the next piece towards a fix for (the x86_64 ABI issues affecting)
PR 88873. This patch generalizes the recent tweak to ix86_expand_move
for setting the highpart of a TImode reg from a DImode source using
*insvti_highpart_1, to handle both DImode and DFmode sources, and also
use the
1 - 100 of 135 matches
Mail list logo
