This patch enables MVE vld4/vst4 instructions for auto-vectorization.
We move the existing expanders from neon.md and enable them for MVE,
calling the respective emitter.
2021-03-12 Christophe Lyon
gcc/
* config/arm/neon.md (vec_load_lanesxi)
(vec_store_lanexoi): Move
This patch enables MVE vld2/vst2 instructions for auto-vectorization.
We move the existing expanders from neon.md and enable them for MVE,
calling the respective emitter.
2021-03-12 Christophe Lyon
gcc/
* config/arm/neon.md (vec_load_lanesoi)
(vec_store_lanesoi): Move
0
.word 0
.word 0
.word 0
.word 1
.word 1
.word 1
.word 1
For some reason emit_move_insn (zero, CONST0_RTX (cmp_mode)) produces
a pair of vldr instead of vmov.i32, qX, #0
2021-03-01 Christophe Lyon
gcc/
* con
This patch adds __fp16 support to the previous patch that added vcmp
support with MVE. For this we update existing expanders to use VDQWH
iterator, and add a new expander vcond. In the
process we need to create suitable iterators, and update v_cmp_result
as needed.
2021-04-26 Christophe Lyon
This patch brings more unification in the vector comparison builtins,
by removing the useless 's' (signed) suffix since we no longer need
unsigned versions.
2021-03-01 Christophe Lyon
gcc/
* config/arm/arm_mve.h (__arm_vcmp*): Remove 's' suffix.
Like in the previous, we factorize the vcmp_*f* patterns to make
maintenance easier.
2021-03-12 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_FP_COMPARISONS): New.
* config/arm/mve.md (mve_vcmpq_f)
(mve_vcmpq_n_f): New, merge all vcmp_*f*
patterns
comparison operators than Neon,
so we have to introduce dedicated iterators.
2021-03-01 Christophe Lyon
gcc/
* config/arm/iterators.md (MVE_COMPARISONS): New.
(mve_cmp_op): New.
(mve_cmp_type): New.
* config/arm/mve.md (mve_vcmpq_): New, merge all
After the previous patch, we no longer need to emit the unsigned
variants of vcmpneq/vcmpeqq. This patch removes them as well as the
corresponding iterator entries.
2021-03-01 Christophe Lyon
gcc/
* config/arm/arm_mve_builtins.def (vcmpneq_u): Remove.
(vcmpneq_n_u
There is no need to have a signed and an unsigned version of these
builtins. This is similar to what we do for Neon in arm_neon.h.
This mechanical patch enables later cleanup patches.
2021-03-01 Christophe Lyon
gcc/
* config/arm/arm_mve.h (__arm_vcmpeq*u*, __arm_vcmpne*u
This patch adds a test for the scalar mode of vadd, precisely noting
that we do not yet use the T2 variants of vadd, which take a scalar as
final argument.
2021-04-22 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/mve-vadd-scalar-1: New.
---
.../gcc.target/arm/simd/mve
Support for vmul has been present for a while, but it was lacking a
test for the scalar variant.
This patch adds one, precisely noting that we do not yet use the T2
variants of vmul, which take a scalar as final argument.
2021-04-22 Christophe Lyon
gcc/testsuite/
* gcc.target
This patchs adds a test similar to mve-vsub_1.c, but operates on a
scalar as second argument. For the moment we do not select the T2 vsub
variant operating on a scalar final argument, and we use vadd of the
opposite.
2021-04-26 Christophe Lyon
gcc/testsuite/
* gcc.target/arm
On Tue, 27 Apr 2021 at 14:04, Prathamesh Kulkarni
wrote:
>
> On Tue, 27 Apr 2021 at 17:02, Christophe Lyon via Gcc-patches
> wrote:
> >
> > Support for vadd has been present for a while, but it was lacking a
> > test.
> >
> > 2021-04-22 Christop
Support for vadd has been present for a while, but it was lacking a
test.
2021-04-22 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/mve-vadd-1.c: New.
---
gcc/testsuite/gcc.target/arm/simd/mve-vadd-1.c | 43 ++
1 file changed, 43 insertions
Use a template macro to factorize the existing test functions.
This patch also adds a version to check subtraction with __fp16 type.
2021-04-26 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/mve-vsub_1.c: Factorize and add __fp16 test.
---
gcc/testsuite/gcc.target/arm
Vector right shifts by immediate use vshr, while right shifts by
vectors instead use vneg and vshl.
This patch adds the corresponding scan-assembler-times that were
missing.
2021-04-22 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/mve-vshr.c: Add more scan-assembler
When an iterator cannot be expanded, it is helpful to see the expanded
name which is causing problems. It would be better to also print the
current iterator value (which couldn't match), but I couldn't find
how.
2021-03-01 Christophe Lyon
gcc/
* genflags.c (gen_in
On Mon, 26 Apr 2021 at 10:55, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > Some of the CMSE tests have 'dg-do run', but qemu-arm does not support
> > the privileged instructions involved; one has to use qemu-system-arm
> >
s arm-linux-gnueabi when forcing -march=armv5t.
2021-04-22 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/unsigned-float.c: Remove arm_fp_ok, adjust
dg-options.
---
gcc/testsuite/gcc.target/arm/unsigned-float.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On Wed, 21 Apr 2021 at 14:05, Richard Sandiford via Gcc-patches
wrote:
>
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 15/04/2021 18:45, Richard Sandiford wrote:
> >> Looks good in general, but like you say, it's GCC 12 material.
> >
> > Thanks for the review. The attached patch addresses thes
excess errors)
gcc.target/arm/pr95646.c check-function-bodies __acle_se_bar
gcc.target/arm/pr95646.c scan-assembler-not mov\tr9, r0
and all cmse tests
2021-04-22 Christophe Lyon
gcc/
* config/arm/arm.h (CPP_SPEC): Remove error message about
-mfloat-abi.
---
gcc/config
-04-22 Christophe Lyon
gcc/
* doc/sourcebuild.texi (arm_qbit_ok): Rename into...
(arm_sat_ok): ...this.
gcc/testsuite/
* gcc.target/arm/acle/saturation.c: Use arm_sat_ok effective
target.
* lib/target-supports.exp
On Mon, 19 Apr 2021 at 12:40, Tobias Burnus wrote:
>
> On 19.04.21 11:25, Tobias Burnus wrote:
> > On 19.04.21 10:48, Christophe Lyon wrote:
> >> The new test generates an ICE on aarch64-linux-gnu in the gcc-10 branch:
> > Looks as someone (like me) should backpor
On Fri, 16 Apr 2021 at 13:29, Richard Sandiford via Gcc-patches
wrote:
>
> Jakub Jelinek writes:
> > On Thu, Apr 15, 2021 at 08:51:03PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> >> Fixed, thanks for catching that (and the "r" -> "=r"; I've
> >> actually tested a patch that didn't have an
re or another
simulator.
2021-04-19 Christophe Lyon
gcc/
* doc/sourcebuild.texi (arm_cmse_hw): Document.
gcc/testsuite/
* gcc.target/arm/cmse/bitfield-1.c: Remove dg-do.
* gcc.target/arm/cmse/bitfield-2.c: Likewise.
* gcc.target/a
Hi,
On Fri, 9 Apr 2021 at 18:44, Hafiz Abid Qadeer wrote:
>
> Thanks for the review. Please see my comments below.
>
> On 09/04/2021 13:48, Tobias Burnus wrote:
> > Hi Abid,
> >
> > I think that's the same issue as https://gcc.gnu.org/PR98088
> > if so, please add 'PR middle-end/98088' to the c
On Thu, 15 Apr 2021 at 17:19, Richard Sandiford via Gcc-patches
wrote:
>
> A lot of the SVE assembly tests are for generic-tuned SVE codegen
> and so can fail when run on a toolchain configured with --with-cpu.
>
> This could easily be solved by forcing -mtune=generic, like we already
> do for -mo
Hi,
On Wed, 14 Apr 2021 at 02:20, Jason Merrill via Gcc-patches
wrote:
>
> PR49951 complained about the debugger jumping back to the declaration of a
> local variable when we run its destructor. That was fixed in 4.7, but broke
> again in 4.8. PR58123 fixed an inconsistency in the behavior, but
On Tue, 13 Apr 2021 at 21:50, Martin Sebor via Gcc-patches
wrote:
>
> The issue has been fixed so r11-8161 just adds the test case:
>https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec
>
Hi,
This new test fails on arm (and aarch64 with -mabi=ilp32):
XFAIL: gcc.dg/pr86058.c pr?
ping?
On Tue, 6 Apr 2021 at 14:02, Christophe Lyon wrote:
>
> ping?
>
> On Mon, 29 Mar 2021 at 11:01, Christophe Lyon
> wrote:
> >
> > The previous change to this testcase missed the fact that the data may
> > be accessed via an anchor, depending on the optimiz
ping?
On Mon, 29 Mar 2021 at 11:01, Christophe Lyon
wrote:
>
> The previous change to this testcase missed the fact that the data may
> be accessed via an anchor, depending on the optimization level,
> leading to false failures.
>
> This patch restricts matching to upper16:l
Hi,
On Wed, 31 Mar 2021 at 11:38, Jan Hubicka wrote:
>
> Hi,
> in the dicussion on PR 99447 there was some confusion about release_body
> being used in context where call edges/references survive. This is not
> a valid use because it would leave stale pointers to ggc_freed memory
> location. By a
On Wed, 31 Mar 2021 at 12:08, Richard Biener wrote:
>
> On Mon, Mar 29, 2021 at 1:40 PM Christophe Lyon via Gcc-patches
> wrote:
> >
> > The vectorizer has a very different effect with -mabi=ilp32, and
> > doesn't emit the expecte diagnostic, so this patch expect
On Tue, 30 Mar 2021 at 14:59, Richard Earnshaw
wrote:
>
>
>
> On 30/03/2021 13:37, Christophe Lyon via Gcc-patches wrote:
> > When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
> > want to emit Tag_ABI_VFP_args even though we are not emitting
> > f
On Mon, 29 Mar 2021 at 12:56, Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: 29 March 2021 11:45
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] aarch64: PR target/99037 Fix RTL represntation in
> > mov
When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
want to emit Tag_ABI_VFP_args even though we are not emitting
floating-point instructions (we need "+mve.fp" for that), because we
use MVE registers to pass FP arguments.
This patch removes the condition on (! TARGET_SOFT_FLOAT) be
On Mon, 29 Mar 2021 at 17:09, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> aarch64 currently doesn't support declare simd where the return value and
> arguments
> have different sizes and warns about that case. This change adds a dg-warning
> for that case like various other tests have alrea
does not support `wldrd wr0,[r0]' in ARM mode
Error: selected processor does not support `wldrd wr2,.L8' in ARM mode
Error: selected processor does not support `wmulwl wr0,wr0,wr2' in ARM mode
Error: selected processor does not support `wstrd wr0,[r0]' in ARM mode
2021-03
The vectorizer has a very different effect with -mabi=ilp32, and
doesn't emit the expecte diagnostic, so this patch expects it only
under lp64.
2021-03-29 Christophe Lyon
gcc/testsuite/
PR target/96974
* g++.target/aarch64/sve/pr96974.C: Expect SLP diagnostic
instead of '[^ \]' would match accross the whole assembly
file, which is not what we want, hence the limitation with spaces.
2021-03-29 Christophe Lyon
gcc/testsuite/
PR target/96770
* gcc.target/arm/pure-code/pr96770.c: Fix scan-assembler-times
with
Hi,
I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used.
I suspect this is because the \\+4 string matches the LTO sections, sometimes.
I propose this small patch to avoid the issue, by matching arr\\+4 instead. OK?
2021-03-26 Christophe Lyon
gcc/test
On Wed, 24 Mar 2021 at 10:45, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes similar issues as in PR98849 -
> in older gcc versions, the expanders were present in neon.md guarded
> with TARGET_NEON, but they got moved to vec-common.md and guarded with
> ARM_HAVE__ARITH so that they han
MVE has different constraints than Neon for load/store: we should use
the Ux constraint instead of Um.
2021-03-24 Christophe Lyon
PR target/99727
gcc/
* config/arm/mve.md (movmisalign_mve_store): Use Ux
constraint.
(movmisalign_mve_load): Likewise
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov wrote:
>
>
> On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
> > On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
> > wrote:
> >>
> > Hi,
> >
> > This patch causes regressions (116) on
On Tue, 23 Mar 2021 at 15:59, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 23 March 2021 14:33
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 8/8] t
Christophe Lyon
gcc/
* doc/sourcebuild.texi (arm_dsp_ok, arm_dsp): Document.
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_dsp_ok_nocache)
(check_effective_target_arm_dsp_ok, add_options_for_arm_dsp): New.
* gcc.target
good way
forward.
2021-03-19 Christophe Lyon
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1m_mve_fp_ok_nocache): Fix
-mfloat-abi= options order.
(check_effective_target_arm_v8_1m_mve_ok_nocache): Likewise
*
arm-linux-gnueabi.
2021-03-19 Christophe Lyon
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_2a_i8mm_ok_nocache): Fix
-mfloat-abi= options order.
(check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): Likewise
instead of reporting a failure.
2021-03-20 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/armv8_2-fp16-scalar-2.c: Add arm_hard_ok.
---
gcc/testsuite/gcc.target/arm/armv8_2-fp16-scalar-2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/testsuite/gcc.target/arm/armv8_2
ady so many arm effective targets, it
doesn't seem like a good way forward.
2021-03-19 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/bfloat16_simd_1_2.c: Add arm_softfp_ok.
* gcc.target/arm/bfloat16_simd_2_2.c: Likewise.
* gcc.target/arm/bfloat16_
when forcing -mfloat-abi=soft in
runtestflags, otherwise we get an error '-mfloat-abi=soft and
-mfloat-abi=hard may not be used together' because we try to compile
with both flags.
2021-03-19 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/armv8_1m-shift-imm-1.c: Rem
We need to add the options corresponding to the arm_v8_2a_i8mm_ok
effective target in order to use the right float-abi option:
-mfloat-abi=softfp makes the test pass for arm-linux-gnueabi,
while no -mfloat-abi option is needed for arm-linux-gnueabihf.
2021-03-19 Christophe Lyon
gcc
and the tests pass.
2021-03-19 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/bfloat16_scalar_typecheck.c: Add
arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon.
* gcc.target/arm/bfloat16_vector_typecheck_1.c: Likewise.
* gcc.target/arm
x27;s still the concern of the complexity of effective-target
settings on arm, these patches do not try to address that.
OK for stage4?
Thanks,
Christophe
Christophe Lyon (8):
testsuite/arm: Add arm_v8_2a_fp16_neon and arm_v8_2a_bf16_neon options
testsuite/arm: Add arm_v8_2a_i8mm optio
On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
wrote:
>
>
> On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
> > Vladimir Makarov writes:
> >> On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
> >>> Vladimir Makarov via Gcc-patches writes:
> The following patch solves P1 P
Please disregard this patch: I'll resubmit it as part of a larger
series, based on similar patches I sent ~1 year ago.
On Wed, 17 Mar 2021 at 19:25, Christophe Lyon
wrote:
>
> Function stacktest1 in bfloat16_scalar_1_1.c test requires
> -mfloat-abi=hard for the associated check-f
As discussed in PR 97680, -fzero-call-used-regs is not supported on
arm.
Skip this test to avoid failure reports.
2021-03-18 Christophe Lyon
gcc/tesuite/
* c-c++-common/zero-scratch-regs-10.c: Skip on arm
---
gcc/testsuite/c-c++-common/zero-scratch-regs-10.c | 1 +
1 file
/softfp by default.
2021-03-17 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/bfloat16_scalar_1_1.c: Require -mfloat-abi=hard
support.
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_1_1.c
index efcc561..7a6c177 100644
--- a/gcc
On Tue, 16 Mar 2021 at 18:38, Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 06:34:34PM +0100, Christophe Lyon wrote:
> > On Sat, 13 Mar 2021 at 21:34, Jakub Jelinek via Gcc-patches
> > Unfortunately, the last new warning does not happen when running the
> > tests with
On Sat, 13 Mar 2021 at 21:34, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As the patch shows, there are several bugs in
> aarch64_simd_clone_compute_vecsize_and_simdlen.
> One is that unlike for function declarations that aren't definitions
> it completely ignores argument types. Such decls
On Wed, 3 Mar 2021 at 15:00, Richard Earnshaw
wrote:
>
> On 02/03/2021 18:35, Christophe Lyon wrote:
> > On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
> > wrote:
> >>
> >> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> >>> On 02/03/
On Mon, 8 Feb 2021 at 18:10, Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Andre Vieira (lists)
> > Sent: 03 February 2021 17:59
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov
> > Subject: [AArch64] Fix vector multiplication costs
> >
> > This patch
On Wed, 3 Mar 2021 at 15:13, Richard Earnshaw (lists)
wrote:
>
> On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> > On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> > wrote:
> >>
> >> Hopefully this change will reduce the number of times
On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
wrote:
>
> Hopefully this change will reduce the number of times Christophe is
> needing to tweak the testsuite.
>
Thanks!
I guess this means we can now do some cleanup in the testsuite?
Did you have a quick look at the amount of tests involv
On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
wrote:
>
> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> > On 02/03/2021 18:10, Christophe Lyon wrote:
> >> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
> >> wrote:
> >>>
> >>>
On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
wrote:
>
> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
> > On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
> >> Ping?
> >>
> >> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
>
Ping?
On Wed, 3 Feb 2021 at 10:01, Christophe Lyon wrote:
>
> Ping?
> I guess that's obvious enough?
>
> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
> wrote:
> >
> > Depending on how the toolchain is configured or how the testsuite is
> > executed
s, to avoid failures on targets
where -shared is not supported.
This happens on Arm where the multilibs are not compiled with -fpic
and link fails because
some relocations are generated which are incompatible with -shared.
commit 01c2ce169a05c8e59c4182796876f7e0754e4b5c
Author: Christophe Lyon
Date
On Tue, 23 Feb 2021 at 18:29, Christophe Lyon
wrote:
>
> As discussed in the PR, the Makefile fragment lacks a double '$' to
> get the return-code from GCC invocation, resulting is CMSE support
> missing from multilibs.
>
> I checked that the simple patch proposed
On Wed, 24 Feb 2021 at 09:38, Richard Biener wrote:
>
> On Tue, 23 Feb 2021, Tamar Christina wrote:
>
> > Hi Richi,
> >
> > The attached testcase ICEs due to a couple of issues.
> > In the testcase you have two SLP instances that share the majority of their
> > definition with each other. One tre
As discussed in the PR, the Makefile fragment lacks a double '$' to
get the return-code from GCC invocation, resulting is CMSE support
missing from multilibs.
I checked that the simple patch proposed in the PR fixes the problem.
2021-02-23 Christophe Lyon
Hau Hsu
PR target/99
On Fri, 12 Feb 2021 at 17:02, Richard Earnshaw
wrote:
>
> On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
> > This test forces -march=armv8.1-m.main, which supports only Thumb mode.
> > However, if the toolchain is not configured --with-thumb, the test
> &g
This test forces -march=armv8.1-m.main, which supports only Thumb mode.
However, if the toolchain is not configured --with-thumb, the test
fails with:
error: target CPU does not support ARM mode
Adding -mthumb to dg-options fixes the problem.
Committed as obvious.
2021-02-12 Christophe Lyon
/-mfloat-abi=hard/-march=armv7e-m+fp (same list)
2021-02-10 Christophe Lyon
gcc/testsuite/
* gcc.dg/pr41574.c: Add dg-skip-if clause.
* gcc.dg/pr59418.c: Likewise.
* gcc.target/arm/cortex-m55-nodsp-flag-hard.c: Likewise.
* gcc.target/arm/cortex-m55-nodsp-flag
On Thu, 14 Jan 2021 at 19:57, Alexandre Oliva wrote:
>
> On Jan 14, 2021, Jonathan Wakely wrote:
>
> >> + /* Got for some 10 cycles, but we're already past that and still
>
> > I can't parse "Got for some 10 cycles". If that's just a typo
>
> Yeah, I meant "Go for ... but if ..." and managed
Ping?
I guess that's obvious enough?
On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
wrote:
>
> Depending on how the toolchain is configured or how the testsuite is
> executed, -mthumb may not be compatible. Like for other tests, skip
> pr97969.c in this case.
>
> For insta
On Mon, 1 Feb 2021 at 10:08, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 29 January 2021 18:18
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] arm: Auto-vectorization
On Tue, 19 Jan 2021 at 18:31, Kyrylo Tkachov via Gcc-patches
wrote:
>
> Hi all,
>
> Since we don't guarantee the ordering of the QC flag in FPSR in the
> saturation intrinsics, we shouldn't be testing for it.
> I want to relax the flags for some of the builtins to enable more
> optimisation but
On Fri, 29 Jan 2021 at 16:03, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 29 January 2021 14:55
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] arm:
This patch enables MVE vornq instructions for auto-vectorization. MVE
vornq insns in mve.md are modified to use ior instead of unspec
expression to support ior3. The ior3 expander is added to
vec-common.md
2021-01-29 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
On Wed, 27 Jan 2021 at 15:03, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 27 January 2021 13:56
> > To: Kyrylo Tkachov
> > Cc: Kyrylo Tkachov via Gcc-patches
> > Subject: Re: arm: Adjust cost of v
On Wed, 27 Jan 2021 at 14:44, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 27 January 2021 13:12
> > To: Kyrylo Tkachov
> > Cc: Kyrylo Tkachov via Gcc-patches
> > Subject: Re: arm: Adjust cost of v
On Wed, 27 Jan 2021 at 10:15, Kyrylo Tkachov wrote:
>
> Hi Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 26 January 2021 18:03
> > To: gcc Patches
> > Subject
Depending on how the toolchain is configured or how the testsuite is
executed, -mthumb may not be compatible. Like for other tests, skip
pr97969.c in this case.
For instance arm-linux-gnueabihf and -march=armv5t in RUNTESTFLAGS.
2021-01-27 Christophe Lyon
gcc/testsuite/
PR target/97969
Neon vector comparisons have a dedicated version when comparing with
constant zero: it means its cost is free.
Adjust the cost in arm_rtx_costs_internal accordingly, for Neon only,
since MVE does not support this.
2021-01-26 Christophe Lyon
gcc/
PR target/98730
* config/arm/arm.c
On Fri, 22 Jan 2021 at 19:28, Christophe Lyon
wrote:
>
> On Thu, 21 Jan 2021 at 21:35, Daniel Engel wrote:
> >
> > Hi Christophe,
> >
> > On Thu, Jan 21, 2021, at 2:29 AM, Christophe Lyon wrote:
> > > On Sat, 16 Jan 2021 at 17:13, Daniel Enge
On Thu, 21 Jan 2021 at 21:35, Daniel Engel wrote:
>
> Hi Christophe,
>
> On Thu, Jan 21, 2021, at 2:29 AM, Christophe Lyon wrote:
> > On Sat, 16 Jan 2021 at 17:13, Daniel Engel wrote:
> > >
> > > Hi Christophe,
> > >
> > > On Fri, Jan 15, 2
On Thu, 21 Jan 2021 at 14:39, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 21 January 2021 13:37
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] Fix t
Like all vcmp intrinsics, __arm_vcmpneq_s8 should return a mve_pred16_t.
2021-01-21 Christophe Lyon
gcc/
* config/arm/arm_mve.h (__arm_vcmpneq_s8): Fix return type.
---
gcc/config/arm/arm_mve.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/arm
On Sat, 16 Jan 2021 at 17:13, Daniel Engel wrote:
>
> Hi Christophe,
>
> On Fri, Jan 15, 2021, at 4:30 AM, Christophe Lyon wrote:
> > On Fri, 15 Jan 2021 at 12:39, Daniel Engel wrote:
> > >
> > > Hi Christophe,
> > >
> > > On Mon, Jan 11, 2
These two tests need:
dg-require-effective-target arm_crypto_ok
dg-add-options arm_crypto
because they use intrinsics that need -mfpu=crypto-neon-fp-armv8.
Committed as obvious.
2021-01-18 Christophe Lyon
gcc/testsuite/
PR target/71233
* gcc.target/arm/simd/vceqz_p64
On Fri, 15 Jan 2021 at 12:39, Daniel Engel wrote:
>
> Hi Christophe,
>
> On Mon, Jan 11, 2021, at 8:39 AM, Christophe Lyon wrote:
> > On Mon, 11 Jan 2021 at 17:18, Daniel Engel wrote:
> > >
> > > On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote:
ping?
On Fri, 6 Nov 2020 at 16:22, Christophe Lyon wrote:
>
> On Thu, 5 Nov 2020 at 12:55, Christophe Lyon
> wrote:
> >
> > On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
> > >
> > > H, Christophe,
> > >
> > > > -O
On Fri, 15 Jan 2021 at 10:42, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 17 December 2020 17:48
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PAT
ping^3?
On Thu, 7 Jan 2021 at 13:20, Christophe Lyon wrote:
>
> ping^2?
>
> On Wed, 30 Dec 2020 at 11:34, Christophe Lyon
> wrote:
> >
> > ping?
> >
> > On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
> > wrote:
> > >
> > > This p
ping^3?
On Thu, 7 Jan 2021 at 13:20, Christophe Lyon wrote:
>
> ping^2?
>
> On Wed, 30 Dec 2020 at 11:34, Christophe Lyon
> wrote:
> >
> > ping?
> >
> > On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
> > wrote:
> > >
> > > T
On Mon, 11 Jan 2021 at 17:18, Daniel Engel wrote:
>
> On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote:
> > On Sat, 9 Jan 2021 at 14:09, Christophe Lyon
> > wrote:
> > >
> > > On Sat, 9 Jan 2021 at 13:27, Daniel Engel wrote:
> > > >
On Sat, 9 Jan 2021 at 14:09, Christophe Lyon wrote:
>
> On Sat, 9 Jan 2021 at 13:27, Daniel Engel wrote:
> >
> > On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote:
> > > On 07/01/2021 00:59, Daniel Engel wrote:
> > > > --snip--
> > > &g
On Sat, 9 Jan 2021 at 13:27, Daniel Engel wrote:
>
> On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote:
> > On 07/01/2021 00:59, Daniel Engel wrote:
> > > --snip--
> > >
> > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote:
> > >
> > >>
> > >> Thanks for working on this, Daniel.
> >
On Fri, 8 Jan 2021 at 10:50, Kyrylo Tkachov wrote:
>
> Hi Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 17 December 2020 17:48
> > To: gcc-patches@gcc.gnu.org
> > Subje
801 - 900 of 2965 matches
Mail list logo
