> 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'
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
are you ok 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.or
> > 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
> 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:
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
> Subje
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
> + if (ot_plus == unknown_optab
> + || ot_minus == unknown_optab
> + || optab_handler (ot_minus, TYPE_MODE (step_vectype)) ==
> CODE_FOR_nothing
> + || optab_handler (ot_plus, TYPE_MODE (step_vectype)) ==
> + CODE_FOR_nothing)
> return false;
>
> Won't optab_handler just retu
(vectorizable_induction): Rework to avoid
directly_supported_p
From: Joel Hutton
Sent: 13 December 2021 15:02
To: Richard Biener ; gcc-patches@gcc.gnu.org;
Tobias Burnus ; Richard Sandiford
Cc: Richard Biener
Subject: Re: GCC 11 backport does not build (no "directly_supported_p&qu
My mistake, reworked patch. Tests are still running.
From: Richard Biener
Sent: 13 December 2021 14:47
To: gcc-patches@gcc.gnu.org ; Tobias Burnus
; Joel Hutton ; Richard Sandiford
Cc: GCC Patches ; Richard Biener
Subject: Re: GCC 11 backport does not build
ok for backport to 11?
From: Richard Sandiford
Sent: 10 December 2021 10:22
To: Joel Hutton
Cc: GCC Patches ; Richard Biener
Subject: Re: pr103523: Check for PLUS/MINUS support
Joel Hutton writes:
> Hi all,
>
> This is to address pr103523.
>
> b
Hi all,
This is to address pr103523.
bootstrapped and regression tested on aarch64.
Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
PR103523 is an ICE on valid code:
void d(float *a, float b, int c) {
float e;
for (; c; c--, e += b)
a[c] = e;
}
This is due to no
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
Updated patch 2 with explanation included in commit message and changes
requested.
Bootstrapped and regression tested on aarch64
> -Original Message-
> From: Joel Hutton
> Sent: 12 November 2021 11:42
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
&
> 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
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
Ping. Is there still interest in refactoring vect-patterns to internal_fn's?
> -Original Message-
> From: Joel Hutton
> Sent: 07 June 2021 14:30
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Biener ; Richard Sandiford
>
> Subject: [vect-patterns][RFC] Refactor
Hi all,
This refactor allows widening patterns (such as widen_plus/widen_minus) to be
represented as
either internal_fns or tree_codes. The widening patterns were originally added
as tree codes with the expectation that they would be refactored later.
[vect-patterns] Refactor as internal_fn's
Hi all,
looking for some feedback on this, one thing I would like to draw attention to
is the fact that this pattern requires 2 separate dependent reductions in the
epilogue.
The accumulator vector for the maximum/minimum elements can be reduced to a
scalar result trivially with a min/max, but
>> gcc/testsuite/ChangeLog:
>>
>> PR target/99102
>> * gcc.target/aarch64/sve/pr99102.c: New test.
>
>(The filename is out of date, but the git hook would catch that.)
Fixed and committed.
>
>>
>> diff --git a/gcc/testsuite/gcc.dg/vect/pr99102.c
>> b/gcc/testsuite/gcc.dg/vect/pr99102.c
>> new
Hi all,
This patch fixes PR99102. For masked gather loads/scatter stores the
'loop_masks' variable was checked to be non-null, but the 'final_mask' was the
actual mask used.
bootstrapped and regression tested on aarch64. Regression tested on aarch64_sve
under qemu.
[Vect] Fix mask check on Scat
Hi Richard,
I've revised the patch, sorry about sloppy formatting in the previous one.
Full bootstrap/regression tests are still running, but the changes are pretty
trivial.
Ok for trunk assuming tests finish clean?
>Joel Hutton writes:
>> @@ -277,6 +277,81 @@ optab_for_t
&code2, &multi_step_cvt,
>> +&interm_types))
>>{
>> /* Binary widening operation can only be supported directly by the
>> architecture. */
>> @@ -4981,10 +5065,20
Hi Richards,
This patch adds support for the V8QI->V8HI case from widening vect patterns as
discussed to target PR98772.
Bootstrapped and regression tested on aarch64.
[aarch64][vect] Support V8QI->V8HI WIDEN_ patterns
In the case where 8 out of every 16 elements are widened using a
widening
> Do you mean a v8qi->v8hi widening subtract or a v16qi->v8hi widening
> subtract?
I mean the latter, that seemed to be what richi was suggesting previously.
> The problem with the latter is that we need to fill the
> extra unused elements with something and remove them later.
That's fair eno
>> So emit a v4qi->v8qi gimple conversion
>> then a regular widen_lo/hi using the existing backend patterns/optabs?
>
>I was thinking of using a v8qi->v8hi convert on each operand followed
>by a normal v8hi subtraction. That's what we'd generate if the target
>didn't define the widening patterns.
>>> In practice this will only affect targets that choose to use mixed
>>> vector sizes, and I think it's reasonable to optimise only for the
>>> case in which such targets support widening conversions. So what
>>> do you think about the idea of emitting separate conversions and
>>> a normal subtr
Hi Richard(s),
I'm just looking to see if I'm going about this the right way, based on the
discussion we had on IRC. I've managed to hack something together, I've
attached a (very) WIP patch which gives the correct codegen for the testcase in
question (https://gcc.gnu.org/bugzilla/show_bug.cgi?
From: Richard Sandiford
Sent: 21 January 2021 13:40
To: Richard Biener
Cc: Joel Hutton via Gcc-patches ; Joel Hutton
Subject: Re: [AArch64] Remove backend support for widen-sub
Richard Biener writes:
> On Thu, 21 Jan 2021, Richard Sandiford wrote:
>
>> Joe
Hi all,
This patch removes support for the widening subtract operation in the aarch64
backend as it is causing a performance regression.
In the following example:
#include
extern void wdiff( int16_t d[16], uint8_t *restrict pix1, uint8_t *restrict
pix2)
{
for( int y = 0; y < 4; y++ )
{
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Add
WIDEN_PLUS/WIDEN_MINUS case.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr97929.c: New test.From 1d7855aab9ea099f244e50baede24c50897f6eb5 Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Wed, 9 Dec 2020 16:51:17 +
Subject
EC_WIDEN_PLUS/MINUS_HI/LO<...>' for VEC_WIDEN_PLUS/MINUS_HI/LO
gcc/ChangeLog:
* tree-pretty-print.c (dump_generic_node): Add case for
VEC_WIDEN_(PLUS/MINUS)_(HI/LO)_EXPR and WIDEN_(PLUS/MINUS)_EXPR.
From 6ec022ddc86e97fd7779bdf075619d2e273c77d0 Mon Sep 17 00:00:00
rks, but IIRC it shows up as a tab
> character in the testsuite result summary too.
Fixed. Minor nits welcome. :)
> OK for the aarch64 bits with the testsuite changes above.
ok?
gcc/ChangeLog:
2020-11-13 Joel Hutton
* config/aarch64/aarch64-simd.md: Add vec_widen_lshift_hi/l
naming
> consistent with other tree codes: WIDEN_PLUS_EXPR instead of
> WIDEN_ADD_EXPR and WIDEN_MINUS_EXPR instead of WIDEN_SUB_EXPR.
> Same idea for the VEC_* codes.
Fixed.
> > gcc/ChangeLog:
> >
> > 2020-11-12 Joel Hutton
> >
> > * expr.c (expand
reme would
> be to have one define_expand and various iterators and attributes.
>
> I think the vec_widen_mult_*_ patterns strike a good balance:
> the use ANY_EXTEND to hide the sign difference while still having
> separate hi and lo patterns:
Done
gcc/ChangeLog:
2020-11-13 Joel H
Hi all,
This patch adds backend patterns for vec_widen_add, vec_widen_sub on aarch64.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
* config/aarch64/aarch64-simd.md: New patterns
vec_widen_saddl_lo/hi_
Hi all,
This patch adds support in the aarch64 backend for the vec_widen_shift
vect-pattern and makes a minor mid-end fix to support it.
All 3 patches together bootstrapped and regression tested on aarch64.
Ok for stage 1?
gcc/ChangeLog:
2020-11-12 Joel Hutton
* config/aarch64
Hi all,
This patch adds widening add and widening subtract patterns to
tree-vect-patterns.
All 3 patches together bootstrapped and regression tested on aarch64.
gcc/ChangeLog:
2020-11-12 Joel Hutton
* expr.c (expand_expr_real_2): add widen_add,widen_subtract cases
* optabs
-09-29 Joel Hutton
PR target/96837
* tree-vect-slp.c (vect_analyze_slp): Do not call
vect_attempt_slp_rearrange_stmts for vector constructors.
gcc/testsuite/ChangeLog:
2020-09-29 Joel Hutton
PR target/96837
* gcc.dg/vect/bb-slp-49.c: New test.From
free to eventually revert it.
Great. Vladimir, Ok for trunk?
Changelog:
2020-01-21 Joel Hutton
PR target/93221
* ira.c (ira): Revert use of simplified LRA algorithm.
gcc/testsuite/ChangeLog:
2020-01-21 Joel Hutton
PR target/93221
* gcc.target/aarch64/p
ventually revert it.
Changelog:
2020-01-21 Joel Hutton
PR target/93221
* ira.c (ira): Revert use of simplified LRA algorithm.
gcc/testsuite/ChangeLog:
2020-01-21 Joel Hutton
PR target/93221
* gcc.target/aarch64/pr9322
Changelog was mangled by thunderbird, updated changelog:
Changelog:
2020-01-21 Joel Hutton
PR target/93221
* ira.c (ira): Revert use of simplified LRA algorithm.
gcc/testsuite/ChangeLog:
2020-01-21 Joel Hutton
PR target/93221
* gcc.target/aarch64
Updated changelog:
Changelog:
2020-01-21 Joel Hutton <mailto:joel.hut...@arm.com>
PR target/93221
* ira.c (ira): Revert use of simplified LRA algorithm.
gcc/testsuite/ChangeLog:
2020-01-21 Joel Hutton <mailto:joel.hut...@arm.com>
PR
t is compiled with -O0. Doesn't it ICE without the attribute
> too?
Done. It's not really necessary, belt and braces.
Updated patch attached
From 1a2980ef6eeb76dbf0556f806a85a4f49ad3ebdd Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Tue, 21 Jan 2020 09:37:48 +
Subject: [
:
2020-01-21 Joel Hutton
* ira.c (ira): Revert use of simplified LRA algorithm.
gcc/testsuite/ChangeLog:
2020-01-21 Joel Hutton
PR bug/93221
* gcc.target/aarch64/pr93221.c: New test.
From 0d9980d2327c61eb99d041a217d6ea5c5b34c754 Mon Sep 17 00:00:00 2001
From: Joel
92391
Tested on x86 and sparc64.
2019-11-26 Joel Hutton
* lib/target-supports.exp: Update vect_char_add target selector
to use its own cache.
From 7ed08950f4440f8605b9df1114edcc8ee834 Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Tue, 26 Nov 2019 17:09:12 +
Subject
t_i] = data[0];
> data[0] = best;
> }
>
> This patch adds some support for this pattern.
>
> This patch addresses Bug 88259.
>
> Regression testing is still in progress,
> This patch does not work correctly with vect-epilogues-nomask, and the
> reason for that
testing is still in progress,
This patch does not work correctly with vect-epilogues-nomask, and the
reason for that is still being investigated.
gcc/ChangeLog:
2019-11-15 Joel Hutton
Tamar Christina
PR tree-optimization/88259
* tree-
tance))
> continue;
>
> before the loop over SLP_TREE_SCALAR_STMTS.
Done.
> + if (!subparts.is_constant () || !(subparts.to_constant ()
> + == CONSTRUCTOR_NELTS (rhs)))
> + continue;
>
> can be better written
> @@ -4061,15 +4201,42 @@ vect_schedule_slp (vec_info *vinfo)
> if (is_a (vinfo))
>
> the ChangeLog doesn't mention this. I guess this isn't necessary
> unless you fail vectorizing late which you shouldn't.
>
It's necessary to avoid:
On 30/10/2019 14:51, Richard Biener wrote:
> On Wed, 30 Oct 2019, Joel Hutton wrote:
>
>> On 30/10/2019 13:49, Richard Biener wrote:
>>> Why do you need this? The vectorizer already creates such CTORs. Any
>>> testcase that you can show?
>> typedef lon
412f996e70636b08d5b615813e..9f8419e4208b7d438ace41892022f93ebcadd019
> 100644
> --- a/gcc/tree-vectorizer.h
> +++ b/gcc/tree-vectorizer.h
> @@ -151,6 +151,10 @@ public:
> /* The root of SLP tree. */
> slp_tree root;
>
> + /* For vector constructors, the constructor stmt that the SLP tree is
> built
> + from, NULL otherwise. */
> + gimple *root_stmt;
>
> as said, make this a stmt_vec_info
>
> Thanks,
> Richard.
>
>
>> gcc/testsuite/ChangeLog:
>>
>> 2019-10-10 Joel Hutton
>>
>> * gcc.dg/vect/bb-slp-40.c: New test.
>> * gcc.dg/vect/bb-slp-41.c: New test.
>>
>>
t? no comments that clarify ;) The vector may be
> used as argument to a call or as source of a store. So I'd simply
> remove this check (and the function).
Done. The thinking was that if the vector was used as a source of a
store the SLP tree would be built from the group
v1.16b
.p2align 3,,7
.L2:
str q0, [x0], 16
cmp x0, x1
bne .L2
ret
.cfi_endproc
.LFE0:
2019-10-11 Joel Hutton joel.hut...@arm.com
* tree-vect-slp.c (vect_analyze_slp_instance): Add case for vector
constructors.
(vect_
Hi all,
I noticed when reading the documentation that BREAK_FROM_IMM_USE_SAFE
was removed at some point in 2006 and replaced with BREAK_FROM_IMM_USE_STMT.
2019-10-10 Joel Hutton joel.hut...@arm.com
* doc/tree-ssa.texi: Update renamed macro name.
From
v1.16b .p2align 3,,7 .L2: str q0, [x0], 16 cmp x0, x1 bne .L2
> ret .cfi_endproc .LFE0:
>
>
>
>
> bootstrapped and tested on aarch64-none-linux-gnu
>
Patch attached:
From 7b9e6d02017ffe6f7ab17cbdd48da41ccc5f6db0 Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Fri, 27 Sep 2019 10:26:00 +01
Hi all,
Currently SLP vectorization can build SLP trees starting from reductions or
from group stores. This patch adds a third starting point: vector constructors.
For the following aarch64 test case (compiled with -O3 -fno-vect-cost-model):
char g_d[1024], g_s1[1024], g_s2[1024];
void test_
Hi Thomas,
I've noticed that SPEC has been failing to build on trunk since the below
commit, do you have access to SPEC? do you know if this is due to a bug in the
patch or a bug in SPEC?
> commit ddeea2110539a432b302401a617ceb5bde191094 (HEAD, refs/bisect/bad)
> Author: tkoenig
> Date: T
g:
2019-07-10 Joel Hutton
* config/arm/arm_cmse.h (cmse_nonsecure_caller): Add
warn_unused_result attribute.
(cmse_check_address_range): Add warn_unused_result attribute.
libgcc/ChangeLog:
2019-07-10 Joel Hutton
* config/arm/cmse.c (cmse_check
On 01/07/2019 18:03, James Greenhalgh wrote:
>> gcc/testsuite/ChangeLog:
>>
>> 2019-06-12 Joel Hutton
>>
>> * gcc.target/aarch64/fmul_scvtf_1.c: New test.
> This testcase will fail on ILP32 targets where unsigned long will still
> live in a '
Ping, plus minor rework (mostly non-functional changes)
gcc/ChangeLog:
2019-06-12 Joel Hutton
* config/aarch64/aarch64-protos.h (aarch64_fpconst_pow2_recip): New
prototype
* config/aarch64/aarch64.c (aarch64_fpconst_pow2_recip): New function
* config/aarch64
aarch64_fpconst_pow_of_2) do the same
>> since
>> this function is only called with HF/SF/DF mode. We could add an
>> assert for
>> SCALAR_FLOAT_MODE_P (but then aarch64_fpconst_pow_of_2 should do
>> the same).
> IMO we should leave it as-is. aarch64.h has:
I'
arate patterns
> (the default versions of the conversions appear to be missing a comment too).
I've added comments to the new and existing patterns
From 5a9dfa6c6eb1c5b9c8c464780b7098058989d472 Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Thu, 13 Jun 2019 11:08:56 +0100
Subject: [PATCH]
s0, w0, #16 // 13 [c=24 l=4] *combine_scvtf_SI_sf3/1
ret // 22 [c=0 l=4] *do_return
g:
scvtf d0, w0, #12 // 13 [c=24 l=4] *combine_scvtf_SI_df3
ret // 22 [c=0 l=4] *do_return
gcc/ChangeLog:
2019-06-12 Joel Hutton
64 matches
Mail list logo
