> @@ -247,6 +248,7 @@ void emit_vlmax_cmp_mu_insn (unsigned, rtx *);
> void emit_vlmax_masked_mu_insn (unsigned, int, rtx *);
> void emit_scalar_move_insn (unsigned, rtx *);
> void emit_nonvlmax_integer_move_insn (unsigned, rtx *, rtx);
> +//void emit_vlmax_reduction_insn (unsigned, rtx *);
Plz
> On 17 Jul 2023, at 07:58, Iain Sandoe wrote
>
>> On 17 Jul 2023, at 07:43, FX Coudert wrote:
>>
>>
>> There is an alternate mechanism relying on system libraries that is possible
>> on darwin specifically (I don’t know for other targets) but it will only
>> work for signed binaries, an
The bit twiddling in union/intersect for the value/mask pair must be
normalized to have the unknown bits with a value of 0 in order to make
the math simpler. Normalizing at construction slowed VRP by 1.5% so I
opted to normalize before updating the bitmask in range-ops, since it
was the only user.
This patch provides a way to set the value/mask pair of known bits
globally, similarly to how we can use set_nonzero_bits for known 0
bits. This can then be used by CCP and IPA to set value/mask info
instead of throwing away the known 1 bits.
In further clean-ups, I will see if it makes sense to
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 17, 2023 7:19 AM
> To: Roger Sayle
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> Subject: Re: [PATCH] Fix bootstrap failure (with g++ 4.8.5) in
> tree-if-conv.cc.
>
> On Fri, Jul 14, 2023 at 8:56 PM Roger Sayle
> wrot
On Jul 17 2023, Christoph Müllner wrote:
> The build process shows a lot of warnings.
Then you are using a bad compiler. The build is 100% -Werror clean.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something com
On Mon, Jul 17, 2023 at 12:21 AM Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, July 17, 2023 7:19 AM
> > To: Roger Sayle
> > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > Subject: Re: [PATCH] Fix bootstrap failure (with g++
On Sun, Jul 16, 2023 at 11:49 PM Christoph Müllner
wrote:
>
> On Fri, Jul 14, 2023 at 12:28 PM Andreas Schwab wrote:
> >
> > Why didn't you test that?
>
> Thanks for reporting, and sorry for introducing this warning.
>
> I test all patches before sending them.
> In the case of RISC-V backend patc
On Mon, Jul 17, 2023 at 9:24 AM Andreas Schwab wrote:
>
> On Jul 17 2023, Christoph Müllner wrote:
>
> > The build process shows a lot of warnings.
>
> Then you are using a bad compiler. The build is 100% -Werror clean.
My host compiler is: gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)
S
> 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
> > > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > >
> > > Subject:
On Jul 17 2023, Christoph Müllner wrote:
> My host compiler is: gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)
Too old.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
optimize_insn_for_speed () in assemble output is not aligned with
splitter condition, and it cause an ICE when building SPEC2017
blender_r.
Not sure if ctrl is supposed to be reliable in assemble output, the patch just
remove that as a walkaround.
Bootstrapped and regtested on x86_64-pc-linux-gnu
> From: Jiang, Haochen
> Sent: 17 July 2023 02:50
>
> > From: Jiang, Haochen
> > Sent: Friday, July 14, 2023 10:50 AM
> >
> > > The recent change in TImode parameter passing on x86_64 results in
> > > the FAIL of pr91681-1.c. The issue is that with the extra
> > > flexibility, the combine pass
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 this between passes.
OK?
gcc/ChangeLog:
* tree-ssa-ccp.cc (ccp_finalize)
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.
OK?
gcc/ChangeLog:
* ipa-prop.cc (ipcp_update_bits)
On Mon, Jul 17, 2023 at 9:31 AM Andrew Pinski wrote:
>
> On Sun, Jul 16, 2023 at 11:49 PM Christoph Müllner
> wrote:
> >
> > On Fri, Jul 14, 2023 at 12:28 PM Andreas Schwab
> > wrote:
> > >
> > > Why didn't you test that?
> >
> > Thanks for reporting, and sorry for introducing this warning.
> >
On Mon, Jul 17, 2023 at 9:44 AM Andreas Schwab wrote:
>
> On Jul 17 2023, Christoph Müllner wrote:
>
> > My host compiler is: gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)
>
> Too old.
Ok understood.
Thanks,
Christoph
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint =
Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
that the subdir configure scripts use the configured value.
* configure.ac (GDCFLAGS): Set default from ${CFLAGS}.
* configure: Regenerate.
* Makefile.in (GDCFLAGS): Substitute @GDCFLAGS@.
---
Makefi
The matching code lacked a check that we end up with a PHI node
in the loop header. This caused us to match a random PHI argument
now catched by the extra PHI_ARG_DEF_FROM_EDGE checking.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/110669
* tr
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 (int32_t * __restrict x,
int32_t n, int res)
{
for (int i = 0; i < n; ++i)
r
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__ or [[...]]
>> syntax. Would that be OK?
>>
>> In more detail:
>>
>> We'd
Address comment.
V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624638.html
I added:
+/* Change insn and Assert the change always happens. */
+static void
+validate_change_or_fail (rtx object, rtx *loc, rtx new_rtx, bool in_group)
+{
+ bool change_p = validate_change (object, l
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 ()
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
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
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
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
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
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:
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
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
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
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
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 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 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
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, 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
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
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
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.
>
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
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
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_
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
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,
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
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.
>
> -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 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
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:
> > >
> > > >
Commited to the trunk, thank you.
-- Original --
From: "Kito Cheng"
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
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: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
>
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 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,
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 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, 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, 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
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
> 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.
>>>
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_
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
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 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
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
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
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
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.
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 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
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.
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
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
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
>
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:
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
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
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/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/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/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 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
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
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 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
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
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 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;
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
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
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
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"
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
>
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
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
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
1 - 100 of 122 matches
Mail list logo