On 25/04/2023 13:30, Richard Biener wrote:
On Mon, 24 Apr 2023, Richard Sandiford wrote:
Richard Biener writes:
On Thu, Apr 20, 2023 at 3:24?PM Andre Vieira (lists) via Gcc-patches
wrote:
Rebased all three patches and made some small changes to the second one:
- removed sub and abd opta
On Mon, 24 Apr 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, Apr 20, 2023 at 3:24?PM Andre Vieira (lists) via Gcc-patches
> > wrote:
> >>
> >> Rebased all three patches and made some small changes to the second one:
> >> - removed sub and abd optabs from commutative_optab_p
On 24/04/2023 12:57, Richard Biener wrote:
On Thu, Apr 20, 2023 at 3:24 PM Andre Vieira (lists) via Gcc-patches
wrote:
Rebased all three patches and made some small changes to the second one:
- removed sub and abd optabs from commutative_optab_p, I suspect this
was a copy paste mistake,
- r
Richard Biener writes:
> On Thu, Apr 20, 2023 at 3:24 PM Andre Vieira (lists) via Gcc-patches
> wrote:
>>
>> Rebased all three patches and made some small changes to the second one:
>> - removed sub and abd optabs from commutative_optab_p, I suspect this
>> was a copy paste mistake,
>> - removed
On Thu, Apr 20, 2023 at 3:24 PM Andre Vieira (lists) via Gcc-patches
wrote:
>
> Rebased all three patches and made some small changes to the second one:
> - removed sub and abd optabs from commutative_optab_p, I suspect this
> was a copy paste mistake,
> - removed what I believe to be a superfluou
Rebased all three patches and made some small changes to the second one:
- removed sub and abd optabs from commutative_optab_p, I suspect this
was a copy paste mistake,
- removed what I believe to be a superfluous switch case in vectorizable
conversion, the one that was here:
+ if (code.is_fn_
On Fri, 17 Mar 2023, Andre Vieira (lists) wrote:
> Hi Richard,
>
> I'm only picking this up now. Just going through your earlier comments and
> stuff and I noticed we didn't address the situation with the gimple::build. Do
> you want me to add overloaded static member functions to cover all
> gim
Hi Richard,
I'm only picking this up now. Just going through your earlier comments
and stuff and I noticed we didn't address the situation with the
gimple::build. Do you want me to add overloaded static member functions
to cover all gimple_build_* functions, or just create one to replace
vect
On Thu, 30 Jun 2022, Joel Hutton wrote:
> > We can go with a private vect_gimple_build function until we sort out the
> > API
> > issue to unblock Tamar (I'll reply to Richards reply with further thoughts
> > on
> > this)
> >
>
> Done.
>
> > > Similarly are you ok with the use of gimple_extra
> We can go with a private vect_gimple_build function until we sort out the API
> issue to unblock Tamar (I'll reply to Richards reply with further thoughts on
> this)
>
Done.
> > Similarly are you ok with the use of gimple_extract_op? I would lean
> towards using it as it is cleaner, but I don'
On Tue, 7 Jun 2022, Richard Sandiford wrote:
> Joel Hutton writes:
> >> > Patches attached. They already incorporated the .cc rename, now
> >> > rebased to be after the change to tree.h
> >>
> >> @@ -1412,8 +1412,7 @@ vect_recog_widen_op_pattern (vec_info *vinfo,
> >>2, op
m: Richard Sandiford
> > Sent: 07 June 2022 09:18
> > To: Joel Hutton
> > Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> > Subject: Re: [ping][vect-patterns] Refactor widen_plus/widen_minus as
> > internal_fns
> >
> > Joel Hutton writes:
>
ocked on this patch.
Joel
> -Original Message-
> From: Joel Hutton
> Sent: 07 June 2022 10:02
> To: Richard Sandiford
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: RE: [ping][vect-patterns] Refactor widen_plus/widen_minus as
> internal_fns
>
> Thank
g
> Subject: Re: [ping][vect-patterns] Refactor widen_plus/widen_minus as
> internal_fns
>
> Joel Hutton writes:
> >> > Patches attached. They already incorporated the .cc rename, now
> >> > rebased to be after the change to tree.h
> >>
> >&
Joel Hutton writes:
>> > Patches attached. They already incorporated the .cc rename, now
>> > rebased to be after the change to tree.h
>>
>> @@ -1412,8 +1412,7 @@ vect_recog_widen_op_pattern (vec_info *vinfo,
>>2, oprnd, half_type, unprom, vectype);
>>
>>tree var = vect
> > Patches attached. They already incorporated the .cc rename, now
> > rebased to be after the change to tree.h
>
> @@ -1412,8 +1412,7 @@ vect_recog_widen_op_pattern (vec_info *vinfo,
>2, oprnd, half_type, unprom, vectype);
>
>tree var = vect_recog_temp_ssa_var (itype
On Tue, 31 May 2022, Joel Hutton wrote:
> > Can you post an updated patch (after the .cc renaming, and code_helper
> > now already moved to tree.h).
> >
> > Thanks,
> > Richard.
>
> Patches attached. They already incorporated the .cc rename, now rebased to be
> after the change to tree.h
@@ -1
> Sent: Tuesday, May 31, 2022 11:08 AM
> To: Richard Biener
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [ping][vect-patterns] Refactor widen_plus/widen_minus as
> internal_fns
>
> > Can you post an updated patch (after the .cc renaming, and c
> Can you post an updated patch (after the .cc renaming, and code_helper
> now already moved to tree.h).
>
> Thanks,
> Richard.
Patches attached. They already incorporated the .cc rename, now rebased to be
after the change to tree.h
Joel
0001-Refactor-to-allow-internal_fn-s.patch
Description:
Joel
>
> > -Original Message-
> > From: Joel Hutton
> > Sent: 13 April 2022 16:53
> > To: Richard Sandiford
> > Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> > Subject: [vect-patterns] Refactor widen_plus/widen_minus as internal_fns
> >
>
ct: [vect-patterns] Refactor widen_plus/widen_minus as internal_fns
>
> Hi all,
>
> These patches refactor the widening patterns in vect-patterns to use
> internal_fn instead of tree_codes.
>
> Sorry about the delay, some changes to master made it a bit messier.
>
> B
Hi all,
These patches refactor the widening patterns in vect-patterns to use
internal_fn instead of tree_codes.
Sorry about the delay, some changes to master made it a bit messier.
Bootstrapped and regression tested on aarch64.
Joel
> > diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-pa
[Review for patch 1]
Joel Hutton writes:
> From e7b3017b7b5879204e9d61760a85cc84beeb4fe0 Mon Sep 17 00:00:00 2001
> From: Joel Hutton
> Date: Wed, 25 Aug 2021 14:31:15 +0100
> Subject: [PATCH 1/3] [vect-patterns] Refactor to allow internal_fn's
>
> Hi all,
>
> This refactor allows widening patte
Just a quick ping to check this hasn't been forgotten.
> -Original Message-
> From: Joel Hutton
> Sent: 12 November 2021 11:42
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>
> Subject: RE: [vect-patterns] Refactor widen_plus/wid
gt;
> Subject: RE: [vect-patterns] Refactor widen_plus/widen_minus as
> internal_fns
>
> > please use #define INCLUDE_MAP before the system.h include instead.
Done.
> > Is it really necessary to build a new std::map for each optab lookup?!
> > That looks quite ugly and
> please use #define INCLUDE_MAP before the system.h include instead.
> Is it really necessary to build a new std::map for each optab lookup?!
> That looks quite ugly and inefficient. We'd usually - if necessary at all -
> build
> a auto_vec > and .sort () and .bsearch () it.
Ok, I'll rework this
On Thu, 11 Nov 2021, Joel Hutton wrote:
> Hi all,
>
> This refactor allows widening vect patterns (such as widen_plus/widen_minus)
> to be represented as
> either internal_fns or tree_codes and replaces the current
> widen_plus/widen_minus with internal_fn versions. This refactor is split into
Hi all,
This refactor allows widening vect patterns (such as widen_plus/widen_minus) to
be represented as
either internal_fns or tree_codes and replaces the current
widen_plus/widen_minus with internal_fn versions. This refactor is split into 3
patches.
Boostrapped and regression tested on aar
28 matches
Mail list logo
