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
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
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,
-
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
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
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
>
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
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
> 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
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,
; 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:
> > >> > Patches att
atch.
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
>
> Thanks Richa
with the use of gimple_extract_op? I would lean towards
using it as it is cleaner, but I don't have strong feelings.
Joel
> -Original Message-
> From: Richard Sandiford
> Sent: 07 June 2022 09:18
> To: Joel Hutton
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re:
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 =
> > 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
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
@@
> 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
On Wed, 25 May 2022, Joel Hutton wrote:
> Ping!
>
> Just checking there is still interest in this. I'm assuming you've been
> busy with release.
Can you post an updated patch (after the .cc renaming, and code_helper
now already moved to tree.h).
Thanks,
Richard.
> Joel
>
> > -Original
Ping!
Just checking there is still interest in this. I'm assuming you've been busy
with release.
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
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/widen_minus as
> internal_fns
>
> >
22 matches
Mail list logo
