On Mon, 17 Apr 2023, Richard Biener wrote:
> On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:
> > If after all, a change to the size of the code and mode
> > bit-fields in rtx_def is necessary, like to still fit 64 bytes
(Sorry: 64 bits, not counting the union u.)
> > such become non-byte sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
>
> Agree.
>
> > Now, with the original code,
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
--- Comment #2 from Frank Heckenbach ---
Since I can't easily upgrade to trunk, I need to know if the warning is bogus
in 12.2 and I can safely disable it, or do I need to worry about the generated
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Andrew Pinski changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 109563, which changed state.
Bug 109563 Summary: accessing 9223372036854775810 or more bytes at offsets [2,
9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at
offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563
Bug ID: 109563
Summary: accessing 9223372036854775810 or more bytes at offsets
[2, 9223372036854775807] and 1 may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
Hi Kewen,
On 2023-04-19 10:53, Kewen.Lin wrote:
Hi Jeff,
on 2023/4/19 10:03, Jiufu Guo wrote:
Hi,
On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.
Like Like PR65484 and PR87306, this patch use vect_hw_misalig to guard
Dup like...
This is primarily Raphael's work. All I did was adjust it to apply to
the trunk and add the new types to generic.md's scheduling model.
The basic idea here is to make sure we have the ability to schedule the
bitmanip instructions with a finer degree of control. Some of the
bitmanip
Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.
The canonicalization should help backends for pattern match. .i.e. x86
backend has lots of vec_merge patterns, combine will create any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jiu Fu Guo :
https://gcc.gnu.org/g:57e7229a29ca0e9929b61051e4f5857f0b41b6c7
commit r14-105-g57e7229a29ca0e9929b61051e4f5857f0b41b6c7
Author: Jiufu Guo
Date: Tue Apr
On Thu, Apr 20, 2023 at 10:56 AM juzhe.zh...@rivai.ai
wrote:
>
> >> The comment above might not sync with your implementation?
> Address comment.
>
> >> Actually, you've allowed TARGET_MIN_VLEN < 128 && riscv_autovec_lmul <
> >> RVV_M2
> Not sure I am on the same page with you. I return
> Date: Wed, 19 Apr 2023 22:16:36 +0200
> From: Bernhard Reutner-Fischer
> On 19 April 2023 21:21:18 CEST, Bernhard Reutner-Fischer
> wrote:
> >Hi H-P!
> >
> >This begs the question iff now (i fear it's not), upon
> >successful match(es), the whole peepholes get re-run
> >again per BB (ATM?),
>> The comment above might not sync with your implementation?
Address comment.
>> Actually, you've allowed TARGET_MIN_VLEN < 128 && riscv_autovec_lmul < RVV_M2
Not sure I am on the same page with you. I return word_mode for this situation,
the auto-vectorization
will be disabled. I have testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
--- Comment #1 from Andrew Pinski ---
>/usr/include/stdio.h:189:24: error: expected ‘,’ or ‘;’ before ‘__attr_dealloc’
Hmm, --disable-multilib is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109562
Bug ID: 109562
Summary: Failed to build native GCC 12.2.0 on RISC-V64 linux
machine
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
> +/* Return the vectorization machine mode for RVV according to LMUL. */
> +machine_mode
> +preferred_simd_mode (scalar_mode mode)
> +{
> + /* We only enable auto-vectorization when TARGET_MIN_VLEN >= 128
> + which is -march=rv64gcv. Since GCC loop vectorizer report ICE
> + when we
1. We should only support len_load/len_store in the first patch before any
other auto-vectorization operation.
I have sent the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616223.html
2. cond_ is the conditional auto-vectorization pattern used by
reduction operation and
All functions should be dropped except "riscv_vector_preferred_simd_mode".
I known you take from "rvv-next". However, the implementation of
"prefer_simd_mode" in "rvv-next" is incorrect.
The most important part of implementing this function is that we should
gurantee compiler will not generate
Hi, Michael. Thanks for extracting patches from "rvv-next". I have several
comments here:
1. I think it's not appropriate and useless to support such many target hook in
the first auto-vec support patch.
You should only support TARGET_VECTORIZE_PREFERRED_SIMD_MODE is enough,
supporting too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109561
Bug ID: 109561
Summary: -Wmaybe-uninitialized false positive false positive
false positive false positive false positive
Product: gcc
Version: 12.2.0
Status:
On Linux/x86_64,
ed32ec26697cc77492d094b31a0d2eebc0535644 is the first bad commit
commit ed32ec26697cc77492d094b31a0d2eebc0535644
Author: Jason Merrill
Date: Tue Apr 18 17:12:17 2023 -0400
c++: fix 'unsigned __int128_t' semantics [PR108099]
caused
FAIL: g++.dg/ext/int128-8.C
On Thu, Apr 20, 2023 at 8:46 AM liuhongt wrote:
>
> 1547 /* If this insn loads a parameter from its stack slot, then it
> 1548 represents a savings, rather than a cost, if the parameter is
> 1549 stored in memory. Record this fact.
> 1550
> 1551 Similarly if we're loading other
This small patch just changes around the code slightly to
make it easier to understand that the cases were handling diamond
shaped BB for both do_store_elim/do_hoist_loads.
There is no effect on code output at all since all of the checks
are the same still.
Note this depends on
After optimization for RA, memory op is not propagated into
instructions(>1), and it make testcases not generate vxorps since
the memory is loaded into the dest, and the dest is never unused now.
So rewrite testcases to make the codegen more stable.
gcc/testsuite/ChangeLog:
*
1547 /* If this insn loads a parameter from its stack slot, then it
1548 represents a savings, rather than a cost, if the parameter is
1549 stored in memory. Record this fact.
1550
1551 Similarly if we're loading other constants from memory (constant
1552 pool, TOC references,
Snapshot gcc-10-20230419 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230419/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
panigstein at hotmail dot com changed:
What|Removed |Added
CC||panigstein at hotmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
Andrew Pinski changed:
What|Removed |Added
Component|other |testsuite
--- Comment #1 from Andrew
On 4/19/23 12:03, Ajit Agarwal wrote:
Hello All:
This is patch-4 to improve ree pass for rs6000 target.
Use ABI interfaces support.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109560
Bug ID: 109560
Summary: new test case g++.dg/ext/int128-8.C from
r14-88-ged32ec26697cc7 fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Hi, Richards.
Since GCC 14 is open and this patch has been boostraped && tested on X86.
Is this patch supporting variable IV OK for the trunk ?
Thanks
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-04-07 09:47
To: gcc-patches
CC: richard.sandiford; rguenther; jeffreyalaw; Juzhe-Zhong
On 4/19/23 12:00, Ajit Agarwal wrote:
Hello All:
This is patch-3 to improve ree pass for rs6000 target.
Main functionality routines to imprve ree pass.
Bootstrapped and regtested on powerpc64-gnu-linux.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For
On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
wrote:
>This patch try to introduce the rwlock and split the read/write to
>unit_root tree and unit_cache with rwlock instead of the mutex to
>increase CPU efficiency. In the get_gfc_unit function, the percentage
>to step into the
For diamond bb phi node detection, there is a check
to make sure bb1 is not empty. But in the case where
bb1 is empty except for a predicate, empty_block_p
will still return true but the minmax code handles
that case already so there is no reason to check
if the basic block is empty.
This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> First, note, 'allocated(f())' throws an error.
Agree.
> Now, with the original code,
>
> is_allocated(f())
>
> The function reference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #2 from Marek Polacek ---
Originally this happened when including boost headers, function_template.hpp in
particular, where newer versions suppress a lot of warnings:
commit b75386f628b46f1060a20b6e015931bac37b7da7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Marek Polacek changed:
What|Removed |Added
Summary|Unexpected |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Bug ID: 109559
Summary: Unexpected -Wmaybe-uninitialized warning when inlining
with system header
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
[+list]
On 19 April 2023 21:21:18 CEST, Bernhard Reutner-Fischer
wrote:
>Hi H-P!
>
>This begs the question iff now (i fear it's not), upon successful match(es),
>the whole peepholes get re-run again per BB (ATM?), exposing more
>opportunities?
>If not, would we want to retry, at least for
Hi!
The subject should be something like
rs6000: Enable REE pass by default
(and no period at the end).
On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote:
> This is the patch-1 for improving ree pass for rs6000 target.
It actually just enables it :-)
The mail body should be the
gcc/
* config/xtensa/xtensa-opts.h: New header.
* config/xtensa/xtensa.h (STRICT_ALIGNMENT): Redefine as
xtensa_strict_align.
* config/xtensa/xtensa.cc (xtensa_option_override): When
-m[no-]strict-align is not specified in the command line set
gcc/
* config/xtensa/xtensa-dynconfig.cc (xtensa_get_config_v4): New
function.
include/
* xtensa-dynconfig.h (xtensa_config_v4): New struct.
(XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION)
(XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #16 from Steve Kargl ---
On Wed, Apr 19, 2023 at 07:15:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:58b7dbf865b146a4e65dbda9be6df78f212c03b6
commit r14-92-g58b7dbf865b146a4e65dbda9be6df78f212c03b6
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58538
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #13)
> Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> text. I suppose one can claim that gfortran should throw an
> error when a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #13 from Steve Kargl ---
On Wed, Apr 19, 2023 at 05:25:20PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
>
> I'm trying to check with the issue reporter how extensive is his
Hi Vladimir,
I have been analyzing a test case for which shrink wrapping fails
(on powerpc, 64bit LE). But if the same test case is slightly modified,
shrink wrapping kicks in.
Here are the two tests:
Test1 (shrink wrapped)
long
foo (long i, long cond)
{
i = i + 1;
if (cond)
bar ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #7 from qinzhao at gcc dot gnu.org ---
Okay, thanks for the comment. I see why this should not work.
Hello All:
This is patch-4 to improve ree pass for rs6000 target.
Use ABI interfaces support.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we see redundant zero and sign
extension
Hello All:
This is patch-3 to improve ree pass for rs6000 target.
Main functionality routines to imprve ree pass.
Bootstrapped and regtested on powerpc64-gnu-linux.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we see redundant zero and sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109551
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Hello All:
This is the patch-2 to improve ree pass for rs6000 target.
Bootstrapped and regtested on powerpc64-gnu-linux.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
For rs6000 target we see redundant zero and sign
extension and done to improve ree
Hello All:
This is the patch-1 for improving ree pass for rs6000 target.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target.
Add ree pass as a default pass for rs6000 target.
2023-04-19 Ajit Kumar Agarwal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
--- Comment #12 from Leandro Lupori ---
(In reply to anlauf from comment #11)
> Do you have anybody else supporting the view that the code in question
> should work as an extension?
>
I know there is some usage of this extension, in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:90361bc6f4edb444e86380b6d1e08475fa74
commit r13-7227-g90361bc6f4edb444e86380b6d1e08475fa74
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #7 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
commit r14-91-g5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 06:06:27 +0200
>
> Patch retracted, at least temporarily. My "understanding"
> may be clouded by looking at an actual bug. Sigh.
Mea culpa. I was looking at the result of one
define_peephole2 and thinking it was due to another, and
also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Jason Merrill changed:
What|Removed |Added
Known to work|13.0|
Summary|[12 Regression]
On Wed, Apr 19, 2023 at 12:52:50PM -0400, Jason Merrill wrote:
> On 4/19/23 12:05, Patrick Palka wrote:
> > On Wed, 19 Apr 2023, Patrick Palka wrote:
> >
> > > Aside from correcting how try_class_unification copies multi-dimensional
> > > 'targs', r13-377-g3e948d645bc908 also made it ggc_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #5 from Martin Uecker ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Uecker from comment #3)
> > I general the pointer could point to the first object of an array that has
> > more elements, or to an
On Wed, Apr 19, 2023 at 12:48:42PM -0400, Jason Merrill wrote:
> On 4/19/23 11:26, Jakub Jelinek wrote:
> > On Wed, Apr 19, 2023 at 11:20:09AM -0400, Jason Merrill wrote:
> > > When I was backporting the earlier 108099 patch I finally saw your
> > > comments on
> > > the PR about the meaning of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #22 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:7b30f13b904f137c77e5180357af7917a3b47af0
commit r12-9447-g7b30f13b904f137c77e5180357af7917a3b47af0
Author: Jason Merrill
On 4/19/23 12:05, Patrick Palka wrote:
On Wed, 19 Apr 2023, Patrick Palka wrote:
Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization. But this is potentially wrong since the call to unify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Uecker from comment #3)
> I general the pointer could point to the first object of an array that has
> more elements, or to an object of a different type.
How so? p in comment 0
On 4/19/23 11:26, Jakub Jelinek wrote:
On Wed, Apr 19, 2023 at 11:20:09AM -0400, Jason Merrill wrote:
When I was backporting the earlier 108099 patch I finally saw your comments on
the PR about the meaning of this pattern with the patch being wrong (and a
regression from 11). This fixes that
Sorry for sending messy patches.
Ignore those messy patches and these following patches are the real patches:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616222.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616225.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
LLM, machine learning and AI likes coding with data types that are weird,
float16, bf16, 8 bit float and 4 bit floats. Longer term, would be nice to
natively support these everywhere. Would be nice to trial run them in the
compiler, sort it all out, so that the implementation experience can
From: Ju-Zhe Zhong
This patch adds sanity tests for basic enabling auto-vectorization.
We should make sure compiler enable auto-vectorization strictly according
to '-march'
For example, '-march=rv32gc_zve32x' can not allow INT64 auto-vectorization.
Since SEW = 64 RVV instructions are illegal
From: Ju-Zhe Zhong
This patch is adding 2 compile option for RVV auto-vectorization.
1. -param=riscv-autovec-preference=
This option is to specify the auto-vectorization approach for RVV.
Currently, we only support scalable and fixed-vlmax.
- scalable means VLA auto-vectorization.
From: Ju-Zhe Zhong
This patch enables auto-vectorization accurately according to '-march'
And add len_load/len_store pattern.
For example, for -march=rv32gc_zve32x, we should allow SEW = 64 RVV
auto-vectorization.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (preferred_simd_mode):
From: Ju-Zhe Zhong
PATCH 1: Add compile option for RVV auto-vectorization.
PATCH 2: Enable basic RVV auto-vectorization.
PATCH 3: Add sanity testcases.
*** BLURB HERE ***
Ju-Zhe Zhong (3):
RISC-V: Add auto-vectorization compile option for RVV
RISC-V: Enable basic auto-vectorization for RVV
Ok to cherrypick for 12? It is in GCC 13 and fixes an
annoying ICE.
Martin
Here is a fix for PR105660.
Bootstrapped and regression tested on x86-64.
Fix ICE related to implicit access attributes for VLA arguments [PR105660]
When constructing the specifier string when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107479
Jose E. Marchesi changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100297
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date:
From: Ju-Zhe Zhong
This patch adds sanity tests for basic enabling auto-vectorization.
We should make sure compiler enable auto-vectorization strictly according
to '-march'
For example, '-march=rv32gc_zve32x' can not allow INT64 auto-vectorization.
Since SEW = 64 RVV instructions are illegal
From: Ju-Zhe Zhong
This patch adds sanity tests for basic enabling auto-vectorization.
We should make sure compiler enable auto-vectorization strictly according
to '-march'
For example, '-march=rv32gc_zve32x' can not allow INT64 auto-vectorization.
Since SEW = 64 RVV instructions are illegal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83904
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6fc8e25cb6b5d720bedd85194b0ad740d75082f4
commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf
Date: Tue
From: Ju-Zhe Zhong
This patch is adding 2 compile option for RVV auto-vectorization.
1. -param=riscv-autovec-preference=
This option is to specify the auto-vectorization approach for RVV.
Currently, we only support scalable and fixed-vlmax.
- scalable means VLA auto-vectorization.
From: Ju-Zhe Zhong
This patch enables auto-vectorization accurately according to '-march'
And add len_load/len_store pattern.
For example, for -march=rv32gc_zve32x, we should allow SEW = 64 RVV
auto-vectorization.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (preferred_simd_mode):
From: Ju-Zhe Zhong
PATCH 1: Add compile option for RVV auto-vectorization.
PATCH 2: Enable basic RVV auto-vectorization.
PATCH 3: Add sanity testcases.
*** BLURB HERE ***
Ju-Zhe Zhong (3):
RISC-V: Add auto-vectorization compile option for RVV
RISC-V: Enable basic auto-vectorization for RVV
From: Ju-Zhe Zhong
This patch is adding 2 compile option for RVV auto-vectorization.
1. -param=riscv-autovec-preference=
This option is to specify the auto-vectorization approach for RVV.
Currently, we only support scalable and fixed-vlmax.
- scalable means VLA auto-vectorization.
From: Ju-Zhe Zhong
This patch enables auto-vectorization accurately according to '-march'
And add len_load/len_store pattern.
For example, for -march=rv32gc_zve32x, we should allow SEW = 64 RVV
auto-vectorization.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (preferred_simd_mode):
From: Ju-Zhe Zhong
PATCH 1: Add compile option for RVV auto-vectorization.
PATCH 2: Enable basic RVV auto-vectorization.
PATCH 3: Add sanity testcases.
*** BLURB HERE ***
Ju-Zhe Zhong (3):
RISC-V: Add auto-vectorization compile option for RVV
RISC-V: Enable basic auto-vectorization for RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107480
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #0)
> I am wondering for
> p.3_1 = p;
> _2 = __builtin_object_size (p.3_1, 0);
>
> why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
> size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107481
Jose E. Marchesi changed:
What|Removed |Added
CC||jemarch at gcc dot gnu.org
Last
On 4/19/23 17:14, Bernhard Reutner-Fischer via Gcc-patches wrote:
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran wrote:
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109556
--- Comment #6 from Jakub Jelinek ---
Indeed, the reduction got stuck at around 1.4M size and didn't reduce further
until I've killed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #1 from Siddhesh Poyarekar ---
The __bdos call itself cannot succeed in main() because it cannot see the
allocation in store(). One way it could succeed is if store() was inlined, but
for some reason it doesn't, even if you make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844
Jose E. Marchesi changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #40 from qinzhao at gcc dot gnu.org ---
I had an initial patch to support the element_count attribute and use this
attribute in builtin_dynamic_object_size(), for the following testing case:
1 #include
2 #include
3 #ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-04-19
1 - 100 of 255 matches
Mail list logo
