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,
> > + __RISCV
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 6ed735d6983..7
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
> "rs6000_se
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
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 t
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
depend
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:
>
> #defi
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.c
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
> > >
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 th
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 stan
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 URL: https://gcc.gnu.org/pipermail/gcc-patches/2023-Jul
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
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(+), 66
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(-)
dif
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 insert
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 a/gcc/for
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 (gfc_add_finali
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
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 (gfc_add_
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:
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
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.
---
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
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 argument.
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)
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:
https://gcc.gnu.org/pipermail/gc
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
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: /vol/gcc/lib/
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 reg_overlap_men
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.
>
> /home/pli/repos/gcc/222/riscv-gnu-toolchain/newlib/n
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:
> > >
> > > https://github.com/ken-matsui/
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 instr
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 backen
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: gcc-patches@
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 comment
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/
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)
(vcmlaq
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 u
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.
* config/arm/iterat
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.
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)
(vcmulq_
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)
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 quest
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 for
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 pr
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:
>
> #defi
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 single
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
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
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)
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 au
> 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 for
> -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 C
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 inde
> 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 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
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 foun
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 (write_expressi
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 69143/65
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 ri
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 wh
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.
>>> Fr
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
conversio
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 ass
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 prof
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 so
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 (one
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 float
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
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
>
>
> *From
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 like
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 autovec
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
[RA][PR10
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, wh
> 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
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 tem
On Wed, 12 Jul 2023 at 17:35, Tobias Burnus wrote:
>
> Now committed as r14-2462-g450b05ce54d3f0.
Hi Tobias,
The newly added tests in above commit -- alloc-11.c and alloc-12.c
seem to fail during execution
on armv8l-unknown-linux-gnueabihf:
Running libgomp:libgomp.c++/c++.exp ...
FAIL: libgomp.c+
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 Sandi
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
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 recen
If the stack frame only contains an alloca area, then
pdp11_expand_epilogue fails to deallocate it, resulting
in callee-saved registers and the return address being
restored from the wrong stack slots. Fixed by adding
|| cfun->calls_alloca to the condition for deallocating
the frame.
Tested with
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
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
std::stoi, std::stol, std::stoul, and std::stod only depend on C89
functions, so don't need to be guarded by _GLIBCXX_USE_C99_STDLIB
std::stoll and std::stoull don't need C99 strtoll and strtoull if
sizeof(long) == sizeof(long long).
std::stol
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, Tamar Christina wrote:
> Hi All,
>
> This patch updates the peeling code to maintain LCSSA during peeling.
> The rewrite also naturally takes into account multiple exits and so it didn't
> make sense to split them off.
>
> For the purposes of peeling the only change for mult
> On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote:
>
> If the stack frame only contains an alloca area, then
> pdp11_expand_epilogue fails to deallocate it, resulting
> in callee-saved registers and the return address being
> restored from the wrong stack slots. Fixed by adding
> || cfu
Rainer Orth writes:
> 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]:
On Thu, Jul 13, 2023 at 7:10 PM Roger Sayle wrote:
>
>
> 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
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here the call A().f() is represented as a COMPOUND_EXPR whose first
operand is the otherwise unused object argument A() and second operand
is the call result (both are TARGET_EXPRs). Within the return statem
On 7/13/23 11:46, Paul Koning via Gcc-patches wrote:
On Jul 13, 2023, at 12:47 PM, Mikael Pettersson wrote:
If the stack frame only contains an alloca area, then
pdp11_expand_epilogue fails to deallocate it, resulting
in callee-saved registers and the return address being
restored from th
On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote:
> On 5/26/23 19:18, Marek Polacek wrote:
> > Since r8-509, we'll no longer create a static temporary var for
> > the initializer '{ 1, 2 }' for num in the attached test because
> > the code in finish_compound_literal is now guarded by
>
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 13, 2023 6:31 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 12/19]middle-end: implement loop peeling and IV
> updates for early break.
>
> On Wed, 28 Jun 2023, Ta
1 - 100 of 126 matches
Mail list logo
