LGTM, but please wait for maintainer review.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added
Hi Christophe,
On 26/11/2020 15:31, Christophe Lyon wrote:
Hi Andre,
Thanks for the quick feedback.
On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira
wrote:
Hi Christophe,
Thanks for these! See some inline comments.
On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
This pat
On 08/12/2020 13:50, Christophe Lyon via Gcc-patches wrote:
Hi,
My 'vand' patch changes the definition of VDQ so that the relevant
modes are enabled only when !TARGET_HAVE_MVE (V8QI, ...), and this
helps writing a simpler expander.
However, vneg is used by vshr (right-shifts by register are
Sorry for the delay, just been reminded I still had this patch
outstanding from last stage 1. Hopefully since it has been mostly
reviewed it could go in for this stage 1?
I addressed the comments and gave the slp-part of vectorizable_call some
TLC to make it work.
I also changed vect_get_slp
On 07/11/2022 11:05, Richard Biener wrote:
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully since it has been mostly reviewed it could go in
for this stage 1?
I addressed the comments and
On 07/11/2022 14:56, Richard Biener wrote:
On Mon, 7 Nov 2022, Andre Vieira (lists) wrote:
On 07/11/2022 11:05, Richard Biener wrote:
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully
.
Bootstrapped and regression tested on aarch64-none-linux-gnu.
OK for trunk?
2022-11-09 Andre Vieira
Kyrylo Tkachov
gcc/ChangeLog:
* config/aarch64/aarch64.h (AARCH64_ISA_RCPC): New Macro.
(TARGET_RCPC): New Macro.
* config/aarch64/atomics.md (atomic_load
Hi,
This patch adds support for the widening LDAPR instructions.
Bootstrapped and regression tested on aarch64-none-linux-gnu.
OK for trunk?
2022-11-09 Andre Vieira
Kyrylo Tkachov
gcc/ChangeLog:
* config/aarch64/atomics.md
(*aarch64_atomic_load_rcpc_zext): New
Here is the latest version and an updated ChangeLog:
2022-11-14 Andre Vieira
Kyrylo Tkachov
gcc/ChangeLog:
* config/aarch64/aarch64.h (AARCH64_ISA_RCPC): New Macro.
(TARGET_RCPC): New Macro.
* config/aarch64/atomics.md (atomic_load): Change
Updated version of the patch to account for the testsuite changes in the
first patch.
On 10/11/2022 11:20, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch adds support for the widening LDAPR instructions.
Bootstrapped and regression tested on aarch64-none-linux-gnu.
OK for trunk
On 14/11/2022 14:12, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: Monday, November 14, 2022 2:09 PM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Richard Sandiford
Subject: Re: [PATCH 1/2] aarch64: Enable the use of LDAPR for load
On 11/11/2022 17:40, Stam Markianos-Wright via Gcc-patches wrote:
Hi all,
This is the 2/2 patch that contains the functional changes needed
for MVE Tail Predicated Low Overhead Loops. See my previous email
for a general introduction of MVE LOLs.
This support is added through the already exis
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 20/04/2023 15:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi all,
This is a series of patches/RFCs to implement support in GCC to be able
to target AArch64's libmvec functions that will be/are being added to glibc.
We have chosen to use the omp prag
On 20/04/2023 17:13, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 20/04/2023 15:51, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi all,
This is a series of patches/RFCs to implement support in GCC to be able
to target AArch64's libmv
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
This is a rebase of Joel's previous patch.
This patch removes the old widen plus/minus tree codes which have been
replaced by internal functions.
gcc/ChangeLog:
2023-04-28 Andre Vieira
Joel Hutton
* doc/generic.texi: Remove old tree codes.
* ex
did make those changes we'd no
longer need to keep around the tc1 variable in
vectorizable_conversion... Let me know what you think.
gcc/ChangeLog:
2023-04-28 Andre Vieira
Joel Hutton
* tree-vect-patterns.cc (vect_gimple_build): New Function.
(vect_re
N_PLUS_HI -> vec_widen_addl_hi_ ->
(u/s)addl2
IFN_VEC_WIDEN_PLUS_LO ->
vec_widen_addl_lo_ -> (u/s)addl
This gives the same functionality as the previous WIDEN_PLUS/WIDEN_MINUS
tree codes which are expanded into VEC_WIDEN_PLUS_LO, VEC_WIDEN_PLUS_H
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 03/05/2023 12:55, Richard Biener wrote:
On Fri, 28 Apr 2023, Andre Vieira (lists) wrote:
Hi,
I'm posting the patches separately now with ChangeLogs.
I made the suggested changes and tried to simplify the code a bit further.
Where internal to tree-vect-stmts I changed most functio
are reservations about making these changes this late in the
development stage, unfortunately I didn't get around to fixing them earlier.
Andre Vieira (3):
arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]
arm: Remove unnecessary zero-extending of MVE predicates before use [PR
107674]
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on aarch64-none-eabi and regression tested on arm-none-eabi
and armeb-none-eabi for armv8.1-m.main+mve.fp.
OK for trunk?
gcc/ChangeL
I meant bootstrapped on aarch64-none-linux-gnu and not none-eabi.
On 24/01/2023 13:40, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
The ACLE defines mve_pred16_t as an unsigned short. This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.
Bootstrapped on
Hi,
This patch teaches GCC that zero-extending a MVE predicate from 16-bits
to 32-bits and then only using 16-bits is a no-op.
It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any
other MVE predicate mode without needing to copy it, using the
TARGET_
Hi,
This patch fixes the way we synthesize MVE predicate immediates and
fixes some other inconsistencies around predicates. For instance this
patch fixes the modes used in the vctp intrinsics, to couple them with
predicate modes with the appropriate lane numbers. For this V2QI is
added to rep
ping. (reattaching patch in the hopes patchwork picks it up).
On 13/01/2023 16:05, Andre Simoes Dias Vieira via Gcc-patches wrote:
Hi,
This patch adds the memory operand of MVE masked stores as input operands to
mimic the 'partial' writes, to prevent erroneous write-after-write
optimizations as
Hi,
This patch adds aarch64 to the list of vect_long_long targets.
Regression tested on aarch64-none-linux-gnu.
OK for trunk?
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_vect_long_long): Add
aarch64 to list of targets supporting long long vector
Looks like the first patch was missing a change I had made to prevent
mve_bool_vec_to_const ICEing if called with a non-vector immediate. Now
included.
On 24/01/2023 13:56, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch fixes the way we synthesize MVE predicate immediates and
On 26/01/2023 15:02, Kyrylo Tkachov wrote:
Hi Andre,
-Original Message-
From: Andre Vieira (lists)
Sent: Tuesday, January 24, 2023 1:41 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
Subject: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
107674
On 26/01/2023 15:06, Kyrylo Tkachov wrote:
Hi Andre,
-Original Message-
From: Andre Vieira (lists)
Sent: Tuesday, January 24, 2023 1:54 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Richard Earnshaw
; Richard Biener ;
Kyrylo Tkachov
Subject: [PATCH 2/3] arm: Remove
This applies cleanly to gcc-12 and regressions for arm-none-eabi look clean.
OK to apply to gcc-12?
On 06/12/2022 11:23, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Simoes Dias Vieira
Sent: Tuesday, December 6, 2022 11:19 AM
To: 'gcc-patches@gcc.gnu.org'
Cc: Kyrylo Tkach
Here's a new version with a more robust test.
OK for trunk?
On 27/01/2023 09:56, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: Friday, January 27, 2023 9:54 AM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw
Subject: Re: [PATC
Changed the testcase to be more robust (as per the discussion for the
first patch).
Still need the OK for the mid-end (simplify-rtx) part.
Kind regards,
Andre
On 27/01/2023 09:59, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: Friday, January 27, 2023 9
Yeah that shouldn't be there, it's from an earlier version of the patch
I wrote where I was experimenting changing the existing modes, I'll
remove it from the ChangeLog.
On 31/01/2023 09:53, Kyrylo Tkachov wrote:
gcc/testsuite/ChangeLog:
* gcc.dg/rtl/arm/mve-vxbi.c: Use new pred
Hi,
This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
Bootstrapped and regression tested on aarch64-none-linux.
OK for trunk?
gcc/ChangeLog:
2022-06-10 Andre Vieira
* config/aarch64/aarch64.md (rbit2): Rename this ...
(@aarch64_rbit): ... this and
On 17/06/2022 11:54, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
This patch adds support for the ACLE Data Intrinsics to the AArch64 port.
Bootstrapped and regression tested on aarch64-none-linux.
OK for trunk?
Sorry for the slow review.
On 19/02/2021 15:05, Vladimir Makarov wrote:
On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
Hi,
This patch makes sure that allocno copies are not created for
unordered modes. The testcases in the PR highlighted a case where an
allocno copy was being created for:
(insn 121 120 123
On 14/06/2021 11:57, Richard Biener wrote:
On Mon, 14 Jun 2021, Richard Biener wrote:
Indeed. For example a simple
int a[1024], b[1024], c[1024];
void foo(int n)
{
for (int i = 0; i < n; ++i)
a[i+1] += c[i+i] ? b[i+1] : 0;
}
should usually see peeling for alignment (though on x86 yo
rylo Tkachov wrote:
-Original Message-
From: Richard Sandiford
Sent: Tuesday, November 15, 2022 6:05 PM
To: Andre Simoes Dias Vieira
Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
Richard Earnshaw
Subject: Re: [PATCH 2/2] aarch64: Add support for widening LDAPR
instructions
"Andre
Hi,
Added an extra step to skip unusable epilogue modes when we know the
target does not support predication. This uses a new function
'support_predication_p' that is generated at build time and checks
whether the target supports at least one optab that can be used for
predicated code-generat
Made the suggested changes.
Regarding the name change to partial vectors, I agree in the name change
since that is the terminology we are using in the loop_vinfo members
too, but is there an actual difference between predication/masking and
partial vectors that I am missing?
OK for trunk?
g
Hi Richard,
Thank you for the review, I've adopted all above suggestions downstream,
I am still surprised how many style things I still miss after years of
gcc development :(
On 17/12/2021 12:44, Richard Sandiford wrote:
@@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
r
.
* gcc.target/aarch64/frintnz_vec.c: New test.
On 03/01/2022 12:18, Richard Biener wrote:
On Wed, 29 Dec 2021, Andre Vieira (lists) wrote:
Hi Richard,
Thank you for the review, I've adopted all above suggestions downstream, I am
still surprised how many style things I still miss after years o
r function.
(finish_cost): Set return argument suggested_unroll_factor.
Regards,
Andre
On 30/11/2021 13:56, Richard Biener wrote:
On Tue, 30 Nov 2021, Andre Vieira (lists) wrote:
On 25/11/2021 12:46, Richard Biener wrote:
Oops, my fault, yes, it does. I would suggest to refactor things so
that
Hi,
This a fix for the regression caused by '[vect] Re-analyze all modes for
epilogues'. The earlier patch assumed there was always at least one
other mode than VOIDmode, but that does not need to be the case.
If we are dealing with a target that does not define more modes for
'autovectorize_v
On 12/01/2022 11:44, Richard Sandiford wrote:
Another alternative would be to push autodetected_vector_mode when the
length is 1 and keep 1 as the starting point.
Richard
I'm guessing we would still want to skip epilogue vectorization if
!VECTOR_MODE_P (autodetected_vector_mode) in that cas
On 12/01/2022 11:59, Richard Biener wrote:
On Wed, 12 Jan 2022, Andre Vieira (lists) wrote:
On 12/01/2022 11:44, Richard Sandiford wrote:
Another alternative would be to push autodetected_vector_mode when the
length is 1 and keep 1 as the starting point.
Richard
I'm guessing we would
On 12/01/2022 12:57, Richard Biener wrote:
On Wed, 12 Jan 2022, Andre Vieira (lists) wrote:
On 12/01/2022 11:59, Richard Biener wrote:
On Wed, 12 Jan 2022, Andre Vieira (lists) wrote:
On 12/01/2022 11:44, Richard Sandiford wrote:
Another alternative would be to push
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all modes for epilogues', skipped
modes that should not be skipped since it used the vector mode provided
by autovectorize_vector_modes to derive the minimum VF required for it.
However, those modes s
On 13/01/2022 12:36, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all modes for epilogues', skipped modes
that should not be skipped since it used the vector mod
On 13/01/2022 14:25, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
On 13/01/2022 12:36, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
This time to the list too (sorry for double email)
Hi,
The original patch '[vect] Re-analyze all
On 14/01/2022 07:08, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
On 13/01/2022 14:25, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
On 13/01/2022 12:36, Richard Biener wrote:
On Thu, 13 Jan 2022, Andre Vieira (lists) wrote:
This time
Hi Christophe,
This patch relaxes the addressing modes for the mve full load and stores
(by full loads and stores I mean non-widening or narrowing loads and
stores resp). The code before was requiring a LO_REGNUM for these, where
this is only a requirement if the load is widening or the store
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
Hi,
The original patch to fix this PR broke the if-conversion of calls into
IFN_MASK_CALL. This patch restores that original behaviour and makes
sure the tests added earlier specifically test inbranch SIMD clones.
Bootstrapped and regression tested on aarch64-none-linux-gnu and
x86_64-pc-li
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x86_64.
Not sure you need one, but yeah I don't know either, it looks like it
fails because:
in-branch vector clones are not yet
On 13/04/2023 15:00, Richard Biener wrote:
On Thu, Apr 13, 2023 at 3:00 PM Andre Vieira (lists) via Gcc-patches
wrote:
On 13/04/2023 11:01, Andrew Stubbs wrote:
Hi Andre,
I don't have a cascadelake device to test on, nor any knowledge about
what makes it different from regular x
Resending this to everyone (sorry for the double send Richard).
On 14/04/2023 09:15, Andre Vieira (lists) wrote:
>
>
> On 14/04/2023 07:55, Richard Biener wrote:
>> On Thu, Apr 13, 2023 at 4:25 PM Andre Vieira (lists)
>> wrote:
>>>
>>>
>>>
>&g
On 14/04/2023 10:09, Richard Biener wrote:
On Fri, Apr 14, 2023 at 10:43 AM Andre Vieira (lists)
wrote:
Resending this to everyone (sorry for the double send Richard).
On 14/04/2023 09:15, Andre Vieira (lists) wrote:
>
>
> On 14/04/2023 07:55, Richard Biener wrote:
>&
I have (outdated) RFC's here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613593.html
I am working on this patch series for stage 1. The list of features I am
working on are:
* SVE support for #pragma omp declare simd
* Support for simdclone usage in autovec from #pragma omp declare v
On the other thread I commented that inbranch simdclones are failing for
AVX512F because it sets the mask_mode, for which inbranch hasn't been
implemented, and so it is rejected.
On 14/04/2023 11:25, Jakub Jelinek via Gcc-patches wrote:
On Fri, Apr 14, 2023 at 10:15:06AM +, Richard Biener
On 14/04/2023 12:47, Richard Biener wrote:
On Fri, Apr 14, 2023 at 11:42 AM Andre Vieira (lists)
wrote:
Ah, but then vect_get_smallest_scalar_type should simply ignore that
pointer in MASK_CALL. It should only look at the arguments relevant
for vectorization. So
diff --git a/gcc/tree
SGTM
On 14/04/2023 12:00, Jakub Jelinek wrote:
On Fri, Apr 14, 2023 at 11:59:02AM +0100, Andre Vieira (lists) wrote:
On the other thread I commented that inbranch simdclones are failing for
AVX512F because it sets the mask_mode, for which inbranch hasn't been
implemented, and so it is rej
k you very much!
Kind regards,
Lou
-Original Message-----
From: Andre Vieira (lists)
Sent: Friday, April 14, 2023 12:30
To: Lou Knauer ; Andrew Pinski
Cc: gcc-patches@gcc.gnu.org; Etienne Renault
Subject: Re: [PATCH] aarch64: Add -mveclibabi=sleefgnu
I have (outdated) RFC's here:
https://g
701 - 765 of 765 matches
Mail list logo
