OK
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-07-18 14:55
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; kito.cheng; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Remove testcase that cannot be compiled because VLEN
limitation
Hi,
Since the latter patch
(https://gcc.gnu.org/pipermail/gcc
Hi,
Since the latter patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624689.html)
forbidden VLEN > 4096, the testcase attribute-20.c is no long need. This is
obvious.
Best,
Lehua
gcc/testsuite/ChangeLog:
* gcc.target/riscv/attribute-20.c: Removed.
---
gcc/testsuite/gcc.ta
On 7/17/23 17:09, Juergen Christ wrote:
> A vec_cmpge produces a negation. Replace this negation by swapping the two
> selection choices of a vec_sel based on the result of the vec_cmpge.
>
> Bootstrapped and regression tested on s390x.
>
> gcc/ChangeLog:
>
> * config/s390/vx-builtins.md:
This patch optimizes the performance of the is_fundamental trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_fundamental_v): Use __is_arithmetic
built-in trait.
(is_fundamental): Likewise. Optimize the ori
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_arithmetic): Use __is_arithmetic
built-in trait.
(is_arithmetic_v): Likewise.
Signed-off-by: Ken
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
gcc
This patch is to dynamic adjust size of VLA vectors according to
TARGET_MIN_VLEN (-march=*zvl*b).
Currently, VNx16QImode is always [16,16] when TARGET_MINV_LEN >= 128.
We are going to add a bunch of VLS modes (V16QI,V32QI,etc), these modes
should always be considered
as having smaller size
I will eventually work on disjunction to somehow optimize, but in the
meantime, this might be a better implementation. Of course, my
benchmark could be wrong.
On Mon, Jul 17, 2023 at 11:24 PM Ken Matsui wrote:
>
> Hi,
>
> I took a benchmark for this.
>
> https://github.com/ken-matsui/gcc-benches/
Hi,
I took a benchmark for this.
https://github.com/ken-matsui/gcc-benches/blob/main/is_fundamental-disjunction.md#mon-jul-17-105937-pm-pdt-2023
template
struct is_fundamental
: public std::bool_constant<__is_arithmetic(_Tp)
|| std::is_void<_Tp>::value
This makes it easier to write tests that safely test features needing
d, v and/or zfh extensions.
check_effective_target_riscv_v checks if the current target allows to
use vector instructions.
add_options_for_riscv_v ask to add an -arch option to change the
target to one like the current one, but
As discussed on last week's patch call, this patch uses either a
straight copy or an opaque pattern that emits the loop as assembly to
optimize cpymem for the 'v' extension.
I used Ju-Zhe Zhong's patch - starting in git with:
Author: zhongjuzhe <66454988+zhongju...@users.noreply.github.com>
Date:
Hello, Nathan,
On Jul 15, 2023, Nathan Sidwell wrote:
> Not commenting on the semantics, but the name seems unfortunate (hello
> bikeshed).
Yeah, it's a bit challenging to express the concept, when the notion of
"alias" is kind of symmetric between decl and target, but the
previously-implemente
Committed as obvious.
commit 6bab2772dbc42ce7a1b29b03ae84e6e434e23c4e
Author: Joern Rennecke
Date: Tue Jul 18 04:28:55 2023 +0100
Tighten regexps in gcc.target/riscv/_Float16-zhinx-1.c .
The original "mv" regexp would match
.ascii "\254\254\375\002e2N6\013\231,\354NDmvVP0]\304
Committed to the trunk, thanks Richard and Juzhe.
1. bootstrap and regression are pass on i386 target (by Pan).
2. no new failed testcases on AArch64 target.
Best,
Lehua
-- Original --
From:
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, July 18, 2023 10:53 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v2] RISC-V: Fix RVV frm run test failure on RV32
LGTM.
juzhe.zh...@rivai.a
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-18 10:49
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Fix RVV frm run test failure on RV32
From: Pan Li
Refine the run test case to avoid interactive checking in RV32, by
separating eac
Thanks Juzhe, addressed conflict and passed RV32/RV64 tests with below PATCH v2.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624723.html
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, July 18, 2023 9:09 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject:
From: Pan Li
Refine the run test case to avoid interactive checking in RV32, by
separating each checks in different functions.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/float-point-frm-run-1.c: Fix run failure.
---
.../riscv/rvv/base/float-point-frm-r
Committed, thanks Jeff and Juzhe.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, July 18, 2023 12:59 AM
To: juzhe.zh...@rivai.ai; Li, Pan2 ; gcc-patches
Cc: Wang, Yanzhang ; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Support basic floating-point dynamic rounding
mode
On 7/1
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-14 21:20
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Fix RVV frm run test failure on RV32
From: Pan Li
Refine the run test case to avoid interactive checking in RV32, by
separating each
This patch is to enable SLP un-order reduction autao-vectorization
Consider this following case:
int __attribute__((noipa))
add_loop (int *x, int n, int res)
{
for (int i = 0; i < n; ++i)
{
res += x[i * 2];
res += x[i * 2 + 1];
}
return res;
}
--param riscv-autovec-prefer
Just for reference, not applying.
-- 8< --
This is what I used to check for what non-constant results we were
previously caching. After the previous two patches it's just address
of a local and a partially-uninitialized COMPLEX_EXPR.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expr
On Mon, Jul 17, 2023 at 09:17:48PM +, Qing Zhao wrote:
>
> > On Jul 13, 2023, at 4:31 PM, Kees Cook wrote:
> >
> > In the bug, the problem is that "p" isn't known to be allocated, if I'm
> > reading that correctly?
>
> I think that the major point in PR109557
> (https://gcc.gnu.org/bugzill
Michael Matz via Gcc-patches writes:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say to memmove/memcpy, eve
Manolis Tsamis writes:
> 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 sequ
On Fri, 14 Jul 2023, Jason Merrill wrote:
> On 7/14/23 14:07, Patrick Palka wrote:
> > On Thu, 13 Jul 2023, Jason Merrill wrote:
> >
> > > On 7/13/23 11:48, Patrick Palka wrote:
> > > > On Wed, 28 Jun 2023, Patrick Palka wrote:
> > > >
> > > > > On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill
>
The RISC-V Ztso extension currently has no effect on generated code.
With the additional ordering constraints guarenteed by Ztso, we can emit
more optimized atomic mappings than the RVWMO mappings.
This PR defines a strengthened version of Andrea Parri's proposed Ztso mappings
("Proposed Mapping"
gcc/ChangeLog:
* doc/extend.texi: Add @cindex on __auto_type.
---
Pushed as obvious.
gcc/doc/extend.texi | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 093bd97ba4d..ec9ffa3c86e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The change to only cache constexpr calls that are
reduced_constant_expression_p tripped on bit-cast3.C, which failed that
predicate due to the presence of an empty field in the result of
native_interpret_aggregate, which reduced_constant_expressi
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In reviewing Nathaniel's patch for PR70331, it occurred to me that instead
of looking for various specific problematic things in the result of a
constexpr call to decide whether to cache it, we should use
reduced_constant_expression_p.
The
> On Jul 13, 2023, at 4:31 PM, Kees Cook wrote:
>
> In the bug, the problem is that "p" isn't known to be allocated, if I'm
> reading that correctly?
I think that the major point in PR109557
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557):
for the following pointer p.3_1,
p.3_1 = p;
Also change some internal variables and function arguments from int to bool.
gcc/ChangeLog:
* combine.cc (struct reg_stat_type): Change last_set_invalid to bool.
(cant_combine_insn_p): Change return type from int to bool and adjust
function body accordingly.
(can_combine_p): Ditto
On Mon, Jul 17, 2023 at 2:30 AM Richard Biener wrote:
>
> On Fri, 14 Jul 2023, Andrew Pinski wrote:
>
> > On Thu, Jul 13, 2023 at 2:54?AM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > The following makes sure that FP x > y ? x : y style max/min operations
> > > are if-converted at the GIM
GCC maintainers:
Version 4, changed the new RS6000_OVLD_VEC_REPLACE_UN case statement
rs6000/rs6000-c.cc. The existing REPLACE_ELT iterator name was changed
to REPLACE_ELT_V along with the associated define_mode_attr. Renamed
VEC_RU to REPLACE_ELT for the iterator name and VEC_RU_char to
REPLACE
GCC maintainers:
The rs6000 function find_instance assumes that it is called for built-
ins with only two arguments. There is no checking for the actual
number of aruguments used in the built-in. This patch adds an
additional parameter to the function call containing the number of
aruguments i
GCC maintianers:
In the process of fixing the powerpc/vec-replace-word-runnable.c test I
found there is an existing issue with function find_instance in rs6000-
c.cc. Per the review comments from Kewen in
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624401.html
The fix for function fin
On Thu, 2023-07-13 at 17:41 +0800, Kewen.Lin wrote:
> 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 th
On 7/12/23 11:54, Patrick Palka wrote:
On Wed, 12 Jul 2023, Patrick Palka wrote:
We're not checking constraints of pointer/reference-to-function conversion
functions during overload resolution, which causes us to ICE on the first
testcase and incorrectly reject the second testcase.
Er, I noti
On 7/12/23 14:47, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? There might be an existing PR for this issue but Bugzilla search
seems to be timing out for me currently.
OK.
-- >8 --
I noticed we were accidentally preventing ourselves f
On 7/17/23 09:45, Jiufu Guo wrote:
Should we decide we would like it in general, it wouldnt be hard to add to
irange. wi_fold() cuurently returns null, it could easily return a bool
indicating if an overflow happened, and wi_fold_in_parts and fold_range would
simply OR the results all togethe
On 7/16/23 19:02, juzhe.zh...@rivai.ai wrote:
LGTM
And as of today, that's all we need ;-)
Thanks,
Jeff
On 7/16/23 09:47, Nathaniel Shead wrote:
On Fri, Jul 14, 2023 at 11:16:58AM -0400, Jason Merrill wrote:
What if, instead of removing the variable from one hash table and adding it
to another, we change the value to, say, void_node?
I have another patch I'm working on after this which does see
Hello,
I wanted to follow up on this, and ask what the next steps would be to
incorporate this patch?
Thanks,
Alexander Westbrooks
On Thu, Jun 29, 2023 at 10:38 PM Alexander Westbrooks
wrote:
> Hello,
>
> I have finished my testing, and updated my patch and relevant Changelogs.
> I added 4 n
A vec_cmpge produces a negation. Replace this negation by swapping the two
selection choices of a vec_sel based on the result of the vec_cmpge.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
* config/s390/vx-builtins.md: New vsel pattern.
gcc/testsuite/ChangeLog:
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> Hi, Richard.
>
> RISC-V port needs to add a bunch VLS modes (V16QI,V32QI,V64QI,...etc)
> There are sharing same REG_CLASS with VLA modes (VNx16QI,VNx32QI,...etc)
>
> When I am adding those VLS modes, the RTL_SSA initialization in VSETVL PASS
>
Thanks so much.
It works!
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624694.html
Is it OK?
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-17 22:31
To: Juzhe-Zhong
CC: gcc-patches
Subject: Re: [PATCH] RTL_SSA: Relax PHI_MODE in phi_setup
Juzhe-Zhong writes:
> Hi, Richard
From: Ju-Zhe Zhong
Hi, Richard.
RISC-V port needs to add a bunch VLS modes (V16QI,V32QI,V64QI,...etc)
There are sharing same REG_CLASS with VLA modes (VNx16QI,VNx32QI,...etc)
When I am adding those VLS modes, the RTL_SSA initialization in VSETVL PASS
(inserted after RA) ICE:
rvv.c:13:1: intern
Juzhe-Zhong writes:
> Hi, Richard.
>
> RISC-V port needs to add a bunch VLS modes (V16QI,V32QI,V64QI,...etc)
> There are sharing same REG_CLASS with VLA modes (VNx16QI,VNx32QI,...etc)
>
> When I am adding those VLS modes, the RTL_SSA initialization in VSETVL PASS
> (inserted after RA) ICE:
> rvv.
On 7/17/23 05:55, Andre Vieira (lists) wrote:
On 11/07/2023 23:28, Jeff Law wrote:
On 7/11/23 04:37, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch fixes PR110610 by including OPTABS_H in the INTERNAL_FN_H
list, as insn-opinit.h is now required by internal-fn.h. This will
I think Andrew is listed as maintainer for tree-ssa, or maybe it's on one of
the Richard's lists?
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Philipp
> Tomsich
> Sent: Tuesday, July 11, 2023 7:51 AM
> To: Jakub Jelinek
> Cc: gcc-pat
On 7/17/23 08:20, Juzhe-Zhong wrote:
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_option_override): Add sorry check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvl-unimplemented-1.c: New test.
* gcc.target/riscv/rvv/base/zvl-unimplemented-2.c: New test.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_option_override): Add sorry check.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvl-unimplemented-1.c: New test.
* gcc.target/riscv/rvv/base/zvl-unimplemented-2.c: New test.
---
gcc/config/riscv/riscv.cc
Jason Merrill writes:
> On Sun, Jul 16, 2023 at 6:50 AM Richard Sandiford
> wrote:
>
>> Jakub Jelinek writes:
>> > On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via
>> Gcc-patches wrote:
>> >> Summary: We'd like to be able to specify some attributes using
>> >> keywords, rather tha
Hello,
On Mon, 17 Jul 2023, Richard Sandiford via Gcc-patches wrote:
> >> There are some existing attributes that similarly affect semantics
> >> in ways that cannot be ignored. vector_size is one obvious example.
> >> But that doesn't make it a good thing. :)
> >...
> > If you had added __arm(b
On Mon, 17 Jul 2023, Richard Biener wrote:
> > > > > OK. Btw, while I didn't spot this during review I would appreciate
> > > > > if the code could use vec.[q]sort, this should work with a lambda as
> > > > > well I think.
> > > >
> > > > That was my first use, but that hits
> > > > https://gc
Hi,
Richard Biener writes:
> On Fri, 14 Jul 2023, Andrew MacLeod wrote:
>
>>
>> On 7/14/23 09:37, Richard Biener wrote:
>> > On Fri, 14 Jul 2023, Aldy Hernandez wrote:
>> >
>> >> I don't know what you're trying to accomplish here, as I haven't been
>> >> following the PR, but adding all these
On Sun, Jul 16, 2023 at 6:50 AM Richard Sandiford
wrote:
> Jakub Jelinek writes:
> > On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via
> Gcc-patches wrote:
> >> Summary: We'd like to be able to specify some attributes using
> >> keywords, rather than the traditional __attribute__ o
Committed the attached patch as r14-2582-g89d0f082b3c95f.
This is about OpenMP's uses_allocators clause to the 'target' directive.
Using the clause with predefined allocators as list arguments is
required if those allocators are used in a target region - unless
there is an 'omp requires dynamic_
> Am 17.07.2023 um 14:38 schrieb Jan Hubicka :
>
>
>>
>>> On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
>>> wrote:
>>>
>>> Hi,
>>> While looking into sphinx3 regression I noticed that vectorizer produces
>>> BBs with overall probability count 120%. This patch fixes it.
>>>
Instead of reading the known zero bits in IPA, read the value/mask
pair which is available.
There is a slight change of behavior here. I have removed the check
for SSA_NAME, as the ranger can calculate the range and value/mask for
INTEGER_CST. This simplifies the code a bit, since there's no spe
On Mon, 17 Jul 2023, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, July 14, 2023 2:35 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 12/19]middle-end: implement loop peeling a
Hi, Richard.
RISC-V port needs to add a bunch VLS modes (V16QI,V32QI,V64QI,...etc)
There are sharing same REG_CLASS with VLA modes (VNx16QI,VNx32QI,...etc)
When I am adding those VLS modes, the RTL_SSA initialization in VSETVL PASS
(inserted after RA) ICE:
rvv.c:13:1: internal compiler error: in
> On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > While looking into sphinx3 regression I noticed that vectorizer produces
> > BBs with overall probability count 120%. This patch fixes it.
> > Richi, I don't know how to create a testcase, but having one would
Hi,
This restores bootstrap by removing the variable causing:
/home/mjambor/gcc/trunk/src/gcc/tree-ssa-loop-ivcanon.cc: In function ‘bool
try_peel_loop(loop*, edge, tree, bool, long int)’:
/home/mjambor/gcc/trunk/src/gcc/tree-ssa-loop-ivcanon.cc:1170:17: error:
variable ‘entry_count’ set bu
On Fri, Jul 14, 2023 at 12:18 PM Tejas Belagod wrote:
>
> On 7/13/23 4:05 PM, Richard Biener wrote:
> > 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
Hi Richard,
This is reworking of patch to extend fold_vec_perm to handle VLA vectors.
The attached patch unifies handling of VLS and VLA vector_csts, while
using fallback code
for ctors.
For VLS vector, the patch ignores underlying encoding, and
uses npatterns = nelts, and nelts_per_pattern = 1.
On Mon, Jul 17, 2023 at 9:35 AM Tamar Christina wrote:
>
> > On Mon, Jul 17, 2023 at 12:21 AM Tamar Christina via Gcc-patches > patc...@gcc.gnu.org> wrote:
> > >
> > > > -Original Message-
> > > > From: Richard Biener
> > > > Sent: Monday, July 17, 2023 7:19 AM
> > > > To: Roger Sayle
>
On 11/07/2023 23:28, Jeff Law wrote:
On 7/11/23 04:37, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch fixes PR110610 by including OPTABS_H in the INTERNAL_FN_H
list, as insn-opinit.h is now required by internal-fn.h. This will
lead to insn-opinit.h, among the other OPTABS_H he
On Mon, Jul 17, 2023 at 9:57 AM Aldy Hernandez via Gcc-patches
wrote:
>
> Currently CCP throws away the known 1 bits because VRP and irange have
> traditionally only had a way of tracking known 0s (set_nonzero_bits).
> With the ability to keep all the known bits in the irange, we can now
> save th
Commited to the trunk, thank you.
-- Original --
From: "Kito Cheng"
On Mon, Jul 17, 2023 at 10:28 AM Hongtao Liu wrote:
>
> I'd like to ping for this patch (only patch 1/2, for patch 2/2, I
> think that may not be necessary).
>
> On Mon, May 15, 2023 at 9:20 AM Hongtao Liu wrote:
> >
> > ping.
> >
> > On Fri, Apr 21, 2023 at 9:55 PM liuhongt wrote:
> > >
> > > >
On Mon, Jul 17, 2023 at 8:44 AM Hongtao Liu wrote:
>
> Ping.
>
> On Tue, Jul 11, 2023 at 5:16 PM liuhongt via Gcc-patches
> wrote:
> >
> > Similar like we did for CMPXCHG, but extended to all
> > ix86_comparison_int_operator since CMPCCXADD set EFLAGS exactly same
> > as CMP.
> >
> > When operand
> -Original Message-
> From: Richard Biener
> Sent: Friday, July 14, 2023 2:35 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 Thu, 13 Jul 2023, Ta
On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> While looking into sphinx3 regression I noticed that vectorizer produces
> BBs with overall probability count 120%. This patch fixes it.
> Richi, I don't know how to create a testcase, but having one would
> be nice.
>
Hi,
try_peel_loop uses gimple_duplicate_loop_body_to_header_edge which subtracts
the profile
from the original loop. However then it tries to scale the profile in a wrong
way
(it forces header count to be entry count).
This eliminates to profile misupdates in the internal loop of sphinx3.
gcc/C
Hi,
when vectorizing 4 times, we sometimes do
for
<4x vectorized body>
for
<2x vectorized body>
for
<1x vectorized body>
Here the second two fors handling epilogue never iterates.
Currently vecotrizer thinks that the middle for itrates twice.
This turns out to be scale_profile_fo
Hi,
While looking into sphinx3 regression I noticed that vectorizer produces
BBs with overall probability count 120%. This patch fixes it.
Richi, I don't know how to create a testcase, but having one would
be nice.
Bootstrapped/regtested x86_64-linux, commited last night (sorry for
late email)
g
LGTM, thanks for the patch :)
On Mon, Jul 17, 2023 at 5:53 PM Lehua Ding wrote:
>
> Hi,
>
> This patch fix target/PR110696, recursively add all implied extensions.
>
> Best,
> Lehua
>
> PR target/110696
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc
> (riscv_subset_
Committed, thanks Kito.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Monday, July 17, 2023 5:33 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com;
pal...@rivosinc.com; jeffreya...@gmail.com; rdapp@gma
Hi,
This patch fix target/PR110696, recursively add all implied extensions.
Best,
Lehua
PR target/110696
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::handle_implied_ext): recur add all implied extensions.
(riscv_subset_list::check_implied_ex
Hi Aldy,
On Mon, Jul 17 2023, Aldy Hernandez wrote:
> Currently IPA throws away the known 1 bits because VRP and irange have
> traditionally only had a way of tracking known 0s (set_nonzero_bits).
> With the ability to keep all the known bits in the irange, we can now
> save this between passes.
>
LGTM, thanks :)
On Mon, Jul 17, 2023 at 4:20 PM Juzhe-Zhong wrote:
>
> This patch add reduc_*_scal to support reduction auto-vectorization.
>
> Use COND_LEN_* + reduc_*_scal to support unordered non-SLP auto-vectorization.
>
> Consider this following case:
> int __attribute__((noipa))
> and_loop
pushed, thanks :)
On Mon, Jul 17, 2023 at 4:59 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> The variable `regno` is currently not used in riscv_regno_ok_for_index_p(),
> which triggers a compiler warning. Let's address this.
>
> Fixes: 423604278ed5 ("riscv: Prepare backend for in
On Fri, 14 Jul 2023, Andrew Pinski wrote:
> On Thu, Jul 13, 2023 at 2:54?AM Richard Biener via Gcc-patches
> wrote:
> >
> > 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
On Fri, 14 Jul 2023, Andrew MacLeod wrote:
>
> On 7/14/23 09:37, Richard Biener wrote:
> > On Fri, 14 Jul 2023, Aldy Hernandez wrote:
> >
> >> I don't know what you're trying to accomplish here, as I haven't been
> >> following the PR, but adding all these helper functions to the ranger
> >> head
On Fri, 14 Jul 2023, Jan Hubicka wrote:
> Hi,
> loop-ch currently does analysis using ranger for all loops to identify
> candidates and then follows by phase where headers are duplicated (which
> breaks SSA and ranger). The second stage does more analysis (to see how
> many BBs we want to duplica
Add an experimental support for native complex operation handling in
the x86 backend. For now it only support add, sub, mul, conj, neg, mov
in SCmode (complex float). Performance gains are still marginal on this
target because there are no particular instructions to speedup complex
operation, excep
On Mon, Jul 17, 2023 at 10:21 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Jul 14, 2023 at 5:58 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> Summary: We'd like to be able to specify some attributes using
> >> keywords, rather than the traditional __attribute__
Add vectors of complex types to vectorize native operations. Because of
the vectorize was designed to work with scalar elements, several functions
and target hooks have to be adapted or duplicated to support complex types.
After that, the vectorization of native complex operations follows exactly
t
Add an optab and rtl operation for the conjugate, called conj,
to expand CONJ_EXPR.
gcc/ChangeLog:
* rtl.def: Add a conj operation in rtl
* optabs.def: Add a conj optab
* optabs-tree.cc (optab_for_tree_code): use the
conj_optab to convert a CONJ_EXPR
* expr
Catch complex rotation by 90° and 270° in fold-const.cc like before,
but now convert them into the new COMPLEX_ROT90 and COMPLEX_ROT270
internal functions. Also add crot90 and crot270 optabs to expose these
operation the backends. So conditionnaly lower COMPLEX_ROT90/COMPLEX_ROT270
by checking if c
Allow the creation and usage of builtins vectors of complex
in C, using __attribute__ ((vector_size ()))
gcc/c-family/ChangeLog:
* c-attribs.cc (vector_mode_valid_p): Add cases for
vectors of complex
(handle_mode_attribute): Likewise
(type_valid_for_vector_size): L
Support registers of complex types in rtl. Also adapt the functions
called during the expand pass to support native complex operations.
gcc/ChangeLog:
* explow.cc (trunc_int_for_mode): Allow complex int modes
* expr.cc (emit_move_complex_parts): Move both parts at the
same
Add a new target hook for complex element creation during
the expand pass, called gen_rtx_complex. The default implementation
calls gen_rtx_CONCAT like before. Then calls to gen_rtx_CONCAT for
complex handling are replaced by calls to targetm.gen_rtx_complex.
gcc/ChangeLog:
* target.def:
Move read_complex_part and write_complex_part to target hooks. Their
signature also change because of the type of argument part is now
complex_part_t. Calls to theses functions are updated accordingly.
gcc/ChangeLog:
* target.def: Define hooks for read_complex_part and
write_compl
Allow the cplxlower pass to identify if an operation does not need
to be lowered through optabs. In this case, lowering is not performed.
The cplxlower pass now has to handle a mix of lowered and non-lowered
operations. A quick access to both parts of a complex constant is
also implemented.
gcc/lt
Hi,
I have recently started a discussion about exposing complex operations directly
to the backends, to better exploit ISA with complex instructions. The title of
the original message is "[RFC] Exposing complex numbers to target backends" [1].
This message starts a serie of 9 patches of the impl
From: Christoph Müllner
The variable `regno` is currently not used in riscv_regno_ok_for_index_p(),
which triggers a compiler warning. Let's address this.
Fixes: 423604278ed5 ("riscv: Prepare backend for index registers")
Reported-by: Juzhe Zhong
Reported-by: Andreas Schwab
Signed-off-by: Chr
on 2023/7/17 14:39, Richard Biener wrote:
> On Mon, Jul 17, 2023 at 4:22 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR110652 and its duplicate PRs show, there could be one
>> build error
>>
>> error: 'new_temp' may be used uninitialized
>>
>> for some build configurations. It's a false positive war
I'd like to ping for this patch (only patch 1/2, for patch 2/2, I
think that may not be necessary).
On Mon, May 15, 2023 at 9:20 AM Hongtao Liu wrote:
>
> ping.
>
> On Fri, Apr 21, 2023 at 9:55 PM liuhongt wrote:
> >
> > > > + if (!TARGET_SSE2)
> > > > +{
> > > > + if (c_dialect_cxx ()
1 - 100 of 122 matches
Mail list logo
