On Sun, 17 Sept 2023 at 20:11, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > After 27de9aa152141e7f3ee66372647d0f2cd94c4b90, there's a following
> > regression:
> > FAIL: gcc.target/aarch64/vect_copy_lane_1.c scan-assembler-times
> > ins\\tv0.s\\[1\\], v1.s\\[0\\] 3
> >
>
Hi,
After 27de9aa152141e7f3ee66372647d0f2cd94c4b90, there's a following regression:
FAIL: gcc.target/aarch64/vect_copy_lane_1.c scan-assembler-times
ins\\tv0.s\\[1\\], v1.s\\[0\\] 3
This happens because for the following function from vect_copy_lane_1.c:
float32x2_t
__attribute__((noinline,
On Wed, 30 Aug 2023 at 19:20, David Malcolm wrote:
>
> On Wed, 2023-08-30 at 11:52 +0530, Prathamesh Kulkarni wrote:
> > On Wed, 30 Aug 2023 at 04:21, David Malcolm
> > wrote:
> > >
> > > On Tue, 2023-08-29 at 11:01 +0530, Prathamesh Kulkarni wrote:
> > > > On Fri, 25 Aug 2023 at 18:15, David
On Wed, 30 Aug 2023 at 04:21, David Malcolm wrote:
>
> On Tue, 2023-08-29 at 11:01 +0530, Prathamesh Kulkarni wrote:
> > On Fri, 25 Aug 2023 at 18:15, David Malcolm via Gcc-patches
> > wrote:
> > >
> > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > > Pushed to trunk as
On Tue, 15 Aug 2023 at 00:05, Christophe Lyon via Gcc-patches
wrote:
>
> Although they look like aliases for u8 and u16, we need to define them
> so that we can handle p8 and p16 suffixes with the general framework.
>
> They will be used by vmull[bt]q_poly intrinsics.
Hi Christophe,
It seems your
On Fri, 25 Aug 2023 at 18:15, David Malcolm via Gcc-patches
wrote:
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> Pushed to trunk as r14-3481-g99a3fcb8ff0bf2.
Hi David,
It seems the new tests FAIL on arm for LTO bootstrap config:
On Thu, 24 Aug 2023 at 08:27, Thiago Jung Bauermann
wrote:
>
> Since commit e7a36e4715c7 "[PATCH] RISC-V: Support simplify (-1-x) for
> vector." these tests fail on aarch64-linux:
>
> === g++ tests ===
>
> Running g++:g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp ...
>
On Wed, 16 Aug 2023 at 14:12, yanzhang.wang--- via Gcc-patches
wrote:
>
> From: Yanzhang Wang
>
> The pattern is enabled for scalar but not for vector. The patch try to
> make it consistent and will convert below code,
(CCing Richard S.)
Hi,
Sorry if this comment is not relevant to the patch but
On Mon, 21 Aug 2023 at 12:27, Richard Biener wrote:
>
> On Sat, 19 Aug 2023, Prathamesh Kulkarni wrote:
>
> > On Fri, 18 Aug 2023 at 17:11, Richard Biener wrote:
> > >
> > > On Fri, 18 Aug 2023, Richard Biener wrote:
> > >
> > > > On Thu, 17 Aug 2023, Prathamesh Kulkarni wrote:
> > > >
> > > > >
On Mon, 21 Aug 2023 at 12:26, Richard Biener wrote:
>
> On Sat, 19 Aug 2023, Prathamesh Kulkarni wrote:
>
> > On Fri, 18 Aug 2023 at 14:52, Richard Biener wrote:
> > >
> > > On Fri, 18 Aug 2023, Richard Sandiford wrote:
> > >
> > > > Richard Biener writes:
> > > > > The following avoids running
On Fri, 18 Aug 2023 at 17:11, Richard Biener wrote:
>
> On Fri, 18 Aug 2023, Richard Biener wrote:
>
> > On Thu, 17 Aug 2023, Prathamesh Kulkarni wrote:
> >
> > > On Tue, 15 Aug 2023 at 14:28, Richard Sandiford
> > > wrote:
> > > >
> > > > Richard Biener writes:
> > > > > On Mon, 14 Aug 2023,
On Fri, 18 Aug 2023 at 14:52, Richard Biener wrote:
>
> On Fri, 18 Aug 2023, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > The following avoids running into somehow flawed logic in fold_vec_perm
> > > for non-VLA vectors.
> > >
> > > Bootstrap & regtest running on
On Tue, 15 Aug 2023 at 14:28, Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, 14 Aug 2023, Prathamesh Kulkarni wrote:
> >> On Mon, 7 Aug 2023 at 13:19, Richard Biener
> >> wrote:
> >> > It doesn't seem to make a difference for x86. That said, the "fix" is
> >> > probably
On Wed, 16 Aug 2023 at 15:21, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> Unfortunately, the patch regressed following tests on ppc64le and
> >> armhf respectively:
> >> gcc.target/powerpc/vec-perm-ctor.c scan-tree-dump-not optimized
> >> "VIEW_CONVERT_EXPR"
> >>
On Tue, 15 Aug 2023 at 16:59, Prathamesh Kulkarni
wrote:
>
> On Mon, 14 Aug 2023 at 18:23, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > On Thu, 10 Aug 2023 at 21:27, Richard Sandiford
> > > wrote:
> > >>
> > >> Prathamesh Kulkarni writes:
> > >> >> static bool
> > >>
On Mon, 14 Aug 2023 at 18:23, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 10 Aug 2023 at 21:27, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> >> static bool
> >> >> is_simple_vla_size (poly_uint64 size)
> >> >> {
> >> >> if (size.is_constant
On Mon, 14 Aug 2023 at 06:39, Vladimir Makarov via Gcc-patches
wrote:
>
> The following patch fixes useless asserts in my latest patch
> implementing output stack pointer reloads.
Hi Vladimir,
It seems that this patch caused the following ICE on aarch64-linux-gnu
while building cp-demangle.c:
On Mon, 7 Aug 2023 at 13:19, Richard Biener wrote:
>
> On Mon, Aug 7, 2023 at 2:05 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote:
> > >
> > > On Thu, 3 Aug 2023, Richard Biener wrote:
> >
On Thu, 10 Aug 2023 at 21:27, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> static bool
> >> is_simple_vla_size (poly_uint64 size)
> >> {
> >> if (size.is_constant ())
> >> return false;
> >> for (int i = 1; i < ARRAY_SIZE (size.coeffs); ++i)
> >> if (size[i] != (i <=
On Tue, 8 Aug 2023 at 15:27, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 4 Aug 2023 at 20:36, Richard Sandiford
> > wrote:
> >>
> >> Full review this time, sorry for the skipping the tests earlier.
> > Thanks for the detailed review! Please find my responses inline
On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote:
>
> On Thu, 3 Aug 2023, Richard Biener wrote:
>
> > On Thu, 3 Aug 2023, Richard Biener wrote:
> >
> > > On Thu, 3 Aug 2023, Prathamesh Kulkarni wrote:
> > >
> > > > On Wed, 2 Aug 2023 at 14:17, Richard Biener via Gcc-patches
> > > > wrote:
> > >
On Fri, 4 Aug 2023 at 20:36, Richard Sandiford
wrote:
>
> Full review this time, sorry for the skipping the tests earlier.
Thanks for the detailed review! Please find my responses inline below.
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > index
On Sun, 6 Aug 2023 at 03:07, Bradley Lucier wrote:
>
> On 8/5/23 4:58 PM, Prathamesh Kulkarni wrote:
> > I don't have comments on the patch, but a new warning will also
> > require a corresponding entry in doc/invoke.texi.
>
> Thank you for your comment.
>
> -Wdisabled-optimization is an
On Fri, 4 Aug 2023 at 23:28, Bradley Lucier via Gcc-patches
wrote:
>
> The patch at the end adds a warning when a tail/sibling call cannot be
> optimized for various reasons.
>
> I built and tested GCC with and without the patch with configuration
>
> Configured with: ../../gcc-mainline/configure
On Thu, 3 Aug 2023 at 18:15, Richard Sandiford
wrote:
>
> can_div_trunc_p (a, b, , ) tries to compute a Q and r that
> satisfy the usual conditions for truncating division:
>
> (1) a = b * Q + r
> (2) |b * Q| <= |a|
> (3) |r| < |b|
>
> We can compute Q using the constant component
On Thu, 3 Aug 2023 at 18:46, Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Prathamesh Kulkarni writes:
> >> On Tue, 25 Jul 2023 at 18:25, Richard Sandiford
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thanks for the rework and sorry for the slow review.
> >> Hi Richard,
> >> Thanks for
On Wed, 2 Aug 2023 at 14:17, Richard Biener via Gcc-patches
wrote:
>
> On Mon, 31 Jul 2023, Jeff Law wrote:
>
> >
> >
> > On 7/28/23 01:05, Richard Biener via Gcc-patches wrote:
> > > The following delays sinking of loads within the same innermost
> > > loop when it was unconditional before.
On Thu, 3 Aug 2023 at 02:54, Andrew Pinski wrote:
>
> On Wed, Aug 2, 2023 at 10:14 AM Andrew Pinski wrote:
> >
> > On Wed, Aug 2, 2023 at 10:13 AM Prathamesh Kulkarni via Gcc-patches
> > wrote:
> > >
> > > On Mon, 31 Jul 2023 at 22:39,
On Mon, 31 Jul 2023 at 22:39, Andrew Pinski via Gcc-patches
wrote:
>
> This is a new version of the patch.
> Instead of doing the matching of inversion comparison directly inside
> match, creating a new function (bitwise_inverted_equal_p) to do it.
> It is very similar to bitwise_equal_p that was
On Tue, 1 Aug 2023 at 05:20, Jeff Law wrote:
>
>
>
> On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> >>
> >> Comparisons between memory and
On Tue, 1 Aug 2023 at 03:13, Prathamesh Kulkarni
wrote:
>
> On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > Comparisons between memory and constants might be done in a smaller mode
> > resulting in smaller constants which might finally end up as
On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> Comparisons between memory and constants might be done in a smaller mode
> resulting in smaller constants which might finally end up as immediates
> instead of in the literal pool.
>
> For example, on s390x a
On Fri, 21 Jul 2023 at 16:52, Martin Uecker via Gcc-patches
wrote:
>
>
>
> This patch adds a warning for allocations with insufficient size
> based on the "alloc_size" attribute and the type of the pointer
> the result is assigned to. While it is theoretically legal to
> assign to the wrong
On Thu, 27 Jul 2023 at 12:04, Richard Biener wrote:
>
> On Wed, 26 Jul 2023, Prathamesh Kulkarni wrote:
>
> > Sorry, I meant PR110280 in subject line (not PR10280).
>
> OK after 13.2 is released and the branch is open again.
Thanks, committed the patch to releases/gcc-13 branch in:
On Tue, 25 Jul 2023 at 18:25, Richard Sandiford
wrote:
>
> Hi,
>
> Thanks for the rework and sorry for the slow review.
Hi Richard,
Thanks for the suggestions! Please find my responses inline below.
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > This is reworking of patch to extend
Sorry, I meant PR110280 in subject line (not PR10280).
On Wed, 26 Jul 2023 at 23:03, Prathamesh Kulkarni
wrote:
>
> Hi Richard,
> Sorry for the delay in backport to gcc-13.
> The attached patch (cherry picked from master) is bootstrapped+tested
> on aarch64-linux-gnu with SVE enabled on gcc-13
Hi Richard,
Sorry for the delay in backport to gcc-13.
The attached patch (cherry picked from master) is bootstrapped+tested
on aarch64-linux-gnu with SVE enabled on gcc-13 branch.
OK to commit to gcc-13 branch ?
Thanks,
Prathamesh
[aarch64/match.pd] Fix ICE observed in PR110280.
gcc/ChangeLog:
On Mon, 17 Jul 2023 at 17:44, Prathamesh Kulkarni
wrote:
>
> 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
On Fri, 21 Jul 2023 at 21:05, Benjamin Priour via Gcc-patches
wrote:
>
> Hi,
>
> Upon David's request I've joined the in progress patch to the below email.
> I hope it makes more sense now.
>
> Best,
> Benjamin.
>
> -- Forwarded message -
> From: Benjamin Priour
> Date: Tue, Jul
On Tue, 18 Jul 2023 at 13:26, Ajit Agarwal via Gcc-patches
wrote:
>
>
> Ping!
>
> please review.
>
> Thanks & Regards
> Ajit
>
>
> This patch improves code sinking pass to sink statements before call to reduce
> register pressure.
> Review comments are incorporated.
>
> For example :
>
> void
On Tue, 18 Jul 2023 at 15:20, Serval Martinot-Lagarde via Gcc-patches
wrote:
>
> SVE generates superflous rev instructions that can be replaced
> by single mov instruction or a pair of (rev, mov) instructions
Hi Serval,
I had added a similar transform to remove pair of rev instructions in:
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 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:
On Mon, 10 Jul 2023 at 16:43, Xi Ruoyao via Gcc-patches
wrote:
>
> On Mon, 2023-07-10 at 10:33 +, Richard Biener wrote:
> > On Fri, 7 Jul 2023, Xi Ruoyao wrote:
> >
> > > If a bit-field is signed and it's wider than the output type, we
> > > must
> > > ensure the extracted result
On Wed, 28 Jun 2023 at 00:05, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > Sorry I forgot to commit this patch, which you had approved in:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615308.html
> >
> > Just for context for the following test:
> >
Hi Richard,
Sorry I forgot to commit this patch, which you had approved in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615308.html
Just for context for the following test:
svint32_t f_s32(int32x4_t x)
{
return svdupq_s32 (x[0], x[1], x[2], x[3]);
}
-O3 -mcpu=generic+sve generates
On Mon, 26 Jun 2023 at 20:33, Christophe Lyon via Gcc-patches
wrote:
>
> After the recent MVE intrinsics re-implementation, LTO stopped working
> because the intrinsics would no longer be defined.
>
> The main part of the patch is simple and similar to what we do for
> AArch64:
> - call
> > > wrote:
> > > >
> > > > On Tue, 20 Jun 2023 at 16:47, Richard Biener
> > > > wrote:
> > > > >
> > > > > On Tue, Jun 20, 2023 at 11:56 AM Prathamesh Kulkarni via Gcc-patches
> > > > > wrote:
> &g
On Thu, 22 Jun 2023 at 18:06, Richard Biener wrote:
>
> On Thu, Jun 22, 2023 at 11:08 AM Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 20 Jun 2023 at 16:47, Richard Biener
> > wrote:
> > >
> > > On Tue, Jun 20, 2023 at 11:56 AM Pra
On Tue, 20 Jun 2023 at 16:47, Richard Biener wrote:
>
> On Tue, Jun 20, 2023 at 11:56 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi Richard,
> > For the following reduced test-case taken from PR:
> >
> > #include "arm_sve.h"
> >
Hi Richard,
For the following reduced test-case taken from PR:
#include "arm_sve.h"
svuint32_t l() {
alignas(16) const unsigned int lanes[4] = {0, 0, 0, 0};
return svld1rq_u32(svptrue_b8(), lanes);
}
compiling with -O3 -mcpu=generic+sve results in following ICE:
during GIMPLE pass: fre
On Tue, 13 Jun 2023 at 12:38, Tejas Belagod via Gcc-patches
wrote:
>
>
>
> From: Richard Sandiford
> Date: Monday, June 12, 2023 at 2:15 PM
> To: Tejas Belagod
> Cc: gcc-patches@gcc.gnu.org , Tejas Belagod
>
> Subject: Re: [PATCH v2] [PR96339] Optimise svlast[ab]
> Tejas Belagod writes:
> >
On Wed, 31 May 2023 at 00:23, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > The s32 case for single constant patch doesn't regress now after the
> > above commit.
> > Bootstrapped+tested on aarch64-linux-gnu, and verified that the new
> > tests pass for
On Fri, 9 Jun 2023 at 17:41, Jonathan Wakely via Gcc-patches
wrote:
>
> Tested powerpc64le-linux. Pushed to trunk.
Hi Jonathan,
This patch causes following regression on armv8l-unknown-linux-gnueabihf:
FAIL: std/format/functions/format.cc execution test
On Thu, 25 May 2023 at 15:26, Prathamesh Kulkarni
wrote:
>
> On Thu, 25 May 2023 at 13:04, Richard Sandiford
> wrote:
> >
> > LGTM, just a couple of comment tweaks:
> >
> > Prathamesh Kulkarni writes:
> > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> > > index
On Thu, 25 May 2023 at 13:04, Richard Sandiford
wrote:
>
> LGTM, just a couple of comment tweaks:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> > index d6fc94015fa..db7ca4c28c3 100644
> > --- a/gcc/config/aarch64/aarch64.cc
> >
On Thu, 25 May 2023 at 01:28, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 24 May 2023 at 15:40, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
On Wed, 24 May 2023 at 15:40, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 22 May 2023 at 14:18, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > Thanks for the suggestions. Does the attached patch look OK ?
> >> >
On Mon, 22 May 2023 at 14:18, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > Thanks for the suggestions. Does the attached patch look OK ?
> > Boostrap+test in progress on aarch64-linux-gnu.
>
> Like I say, please wait for the tests to complete before sending an
On Thu, 18 May 2023 at 22:04, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 18 May 2023 at 13:37, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 16 May 2023 at 00:29, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
On Thu, 18 May 2023 at 13:37, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 16 May 2023 at 00:29, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > After committing the interleave+zip1 patch for vector initialization,
> >> > it
On Tue, 16 May 2023 at 00:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > After committing the interleave+zip1 patch for vector initialization,
> > it seems to regress the s32 case for this patch:
> >
> > int32x4_t f_s32(int32_t x)
> > {
> > return (int32x4_t)
On Fri, 12 May 2023 at 00:45, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
>
> > On Tue, 2 May 2023 at 18:22, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 2 May 2023 at 17:32, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
On Fri, 12 May 2023 at 00:37, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> > b/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> > new file mode 100644
> > index 000..598a51f17c6
> > --- /dev/null
> > +++
On Mon, 24 Apr 2023 at 15:00, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > [aarch64] Recursively intialize even and odd sub-parts and merge with zip1.
> >
> > gcc/ChangeLog:
> > * config/aarch64/aarch64.cc (aarch64_expand_vector_init_fallback):
> > Rename
> >
On Tue, 2 May 2023 at 18:22, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 2 May 2023 at 17:32, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 2 May 2023 at 14:56, Richard Sandiford
> >> > wrote:
> >> >> > [aarch64] Improve code-gen
On Tue, 2 May 2023 at 17:32, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 2 May 2023 at 14:56, Richard Sandiford
> > wrote:
> >> > [aarch64] Improve code-gen for vector initialization with single
> >> > constant element.
> >> >
> >> > gcc/ChangeLog:
> >> > *
On Tue, 2 May 2023 at 14:56, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 25 Apr 2023 at 16:29, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > While digging thru aarch64_expand_vector_init, I noticed it gives
> >> > priority
On Tue, 25 Apr 2023 at 16:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > While digging thru aarch64_expand_vector_init, I noticed it gives
> > priority to loading a constant first:
> > /* Initialise a vector which is part-variable. We want to first try
> >
On Mon, 24 Apr 2023 at 15:02, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > gcc/ChangeLog:
> > * tree-ssa-forwprop.cc (is_combined_permutation_identity): Try to
> > simplify two successive VEC_PERM_EXPRs with single operand and same
> > mask, where mask chooses
> >> > On Tue, 11 Apr 2023 at 19:36, Prathamesh Kulkarni
> >> > wrote:
> >> > >
> >> > > On Tue, 11 Apr 2023 at 14:17, Richard Biener
> >> > > wrote:
> >> > > >
> >> > > > On Wed, Apr 5, 2023 at 10:3
On Fri, 21 Apr 2023 at 20:45, Prathamesh Kulkarni
wrote:
>
> On Fri, 21 Apr 2023 at 14:47, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > Hi,
> > > I tested the interleave+zip1 for vector init patch and it segfaulted
> > > during bootstrap while trying to build
> > >
On Fri, 21 Apr 2023 at 21:00, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > Based on your suggestions in the other thread, the patch uses force_reg
> > to avoid creating pseudo if value is already in a register.
> > Bootstrap+test passes on aarch64-linux-gnu.
> >
Hi Richard,
Based on your suggestions in the other thread, the patch uses force_reg
to avoid creating pseudo if value is already in a register.
Bootstrap+test passes on aarch64-linux-gnu.
OK to commit ?
Thanks,
Prathamesh
[aarch64] Use force_reg instead of copy_to_mode_reg.
Use force_reg instead
On Fri, 21 Apr 2023 at 14:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > I tested the interleave+zip1 for vector init patch and it segfaulted
> > during bootstrap while trying to build
> > libgfortran/generated/matmul_i2.c.
> > Rebuilding with --enable-checking=rtl
On Wed, 12 Apr 2023 at 14:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> >> > wrote:
> >> >> > diff --git
; > > wrote:
> > > >
> > > > On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > > For the following test:
> > > > >
> > >
On Tue, 11 Apr 2023 at 19:36, Prathamesh Kulkarni
wrote:
>
> On Tue, 11 Apr 2023 at 14:17, Richard Biener
> wrote:
> >
> > On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > > For t
On Tue, 31 Jan 2023 at 11:51, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 23 Jan 2023 at 22:26, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
On Tue, 11 Apr 2023 at 14:17, Richard Biener wrote:
>
> On Wed, Apr 5, 2023 at 10:39 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi,
> > For the following test:
> >
> > svint32_t f(svint32_t v)
> > {
> > return svrev_s32 (svrev_s32
On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> > wrote:
> >> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> >> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> >> > index
On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
> >> On GIMPLE it would be
> >>
> >> _1 = { a, ... }; // (a)
> >> _2 = { _1, ... }; // (b)
> >>
> >> but I'm not sure if (b), a VL CTOR of fixed len(?)
Hi,
For the following test:
svint32_t f(svint32_t v)
{
return svrev_s32 (svrev_s32 (v));
}
We generate 2 rev instructions instead of nop:
f:
rev z0.s, z0.s
rev z0.s, z0.s
ret
The attached patch tries to fix that by trying to recognize the following
pattern in
On Mon, 13 Feb 2023 at 11:58, Prathamesh Kulkarni
wrote:
>
> On Fri, 3 Feb 2023 at 12:46, Prathamesh Kulkarni
> wrote:
> >
> > Hi Richard,
> > While digging thru aarch64_expand_vector_init, I noticed it gives
> > priority to loading a constant first:
> > /* Initialise a vector which is
On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
>
> On Fri, 10 Mar 2023, Richard Sandiford wrote:
>
> > Sorry for the slow reply.
> >
> > Prathamesh Kulkarni writes:
> > > Unfortunately it regresses code-gen for the following case:
> > >
> > > svint32_t f(int32x4_t x)
> > > {
> > > return
On Sun, 19 Feb 2023 at 01:01, Maciej W. Rozycki wrote:
>
> On Sat, 18 Feb 2023, Andrew Pinski via Gcc-patches wrote:
>
> > > > If we have division and remainder calculations with the same operands:
> > > >
> > > > a = b / c;
> > > > d = b % c;
> > > >
> > > > We can replace the calculation of
On Fri, 3 Feb 2023 at 12:46, Prathamesh Kulkarni
wrote:
>
> Hi Richard,
> While digging thru aarch64_expand_vector_init, I noticed it gives
> priority to loading a constant first:
> /* Initialise a vector which is part-variable. We want to first try
> to build those lanes which are
On Mon, 6 Feb 2023 at 17:43, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> >> > wrote:
> >> >>
> >> >> On Thu, 2 Feb 2023 at
On Mon, 6 Feb 2023 at 20:14, Roger Sayle wrote:
>
>
> Perhaps I'm missing something (I'm not too familiar with SVE semantics), but
> is there
> a reason that the solution for PR96473 uses a VEC_PERM_EXPR and not just a
> VEC_DUPLICATE_EXPR? The folding of sv1d1rq (svptrue_..., ...) doesn't seem
On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> >> wrote:
> >> >
> >> > Prathamesh Kulkarni writes:
> >> > >> >> > I have attached a
Hi Richard,
While digging thru aarch64_expand_vector_init, I noticed it gives
priority to loading a constant first:
/* Initialise a vector which is part-variable. We want to first try
to build those lanes which are constant in the most efficient way we
can. */
which results in
On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
wrote:
>
> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > >> >> > I have attached a patch that extends the transform if one half is
> > >> >> > dup
> > >> >> > and other is set of constants.
> >
On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> >> > I have attached a patch that extends the transform if one half is dup
> >> >> > and other is set of constants.
> >> >> > For eg:
> >> >> > int8x16_t f(int8_t x)
> >> >> > {
> >> >> > return
On Wed, 1 Feb 2023 at 21:56, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> >> > wrote:
> >> >>
> >> >> On Mon, 5 Dec 2022
ford
> > > wrote:
> > > >
> > > > Prathamesh Kulkarni via Gcc-patches writes:
> > > > > On Fri, 4 Nov 2022 at 14:00, Prathamesh Kulkarni
> > > > > wrote:
> > > > >>
> > > > >> On Mon, 31 Oct 2022 a
On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
> >> wrote:
> >> >
> >> > Richard Sandiford via Gcc-patches writes:
> >> > >
On Mon, 23 Jan 2023 at 22:26, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford
> >> > wrote:
> >> >>
> >> >> Prathamesh Kulkarni
On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > For the following (contrived) test:
> >> >
> >> > void foo(int32x4_t v)
> >> > {
On Wed, 18 Jan 2023 at 20:00, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi Richard,
> > Based on your suggestion in the other thread, the patch uses
> > exact_log2 (INTVAL (operands[2])) >= 0 to gate for vec_merge patterns.
> > Bootstrap+test in progress on aarch64-linux-gnu.
Hi Richard,
Based on your suggestion in the other thread, the patch uses
exact_log2 (INTVAL (operands[2])) >= 0 to gate for vec_merge patterns.
Bootstrap+test in progress on aarch64-linux-gnu.
Does it look OK ?
Thanks,
Prathamesh
[aarch64] Use exact_log2 (INTVAL (operands[2])) >= 0 to gate for
1 - 100 of 361 matches
Mail list logo
