On 27/09/2021 12:54, Richard Biener via Gcc-patches wrote:
On Mon, 27 Sep 2021, Jirui Wu wrote:
Hi all,
I now use the type based on the specification of the intrinsic
instead of type based on formal argument.
I use signed Int vector types because the outputs of the neon builtins
that I am
Hi,
I completely forgot I still had this patch out as well, I grouped it
together with the unrolling because it was what motivated the change,
but it is actually wider applicable and can be reviewed separately.
On 17/09/2021 16:32, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch
On 13/10/2021 13:37, Kyrylo Tkachov wrote:
Hi Andre,
@@ -24276,7 +24271,7 @@ arm_print_operand (FILE *stream, rtx x, int code)
else if (code == POST_MODIFY || code == PRE_MODIFY)
{
asm_fprintf (stream, "[%r", REGNO (XEXP (addr, 0)));
- postinc_reg =
addressing
modes.
gcc/ChangeLog:
2021-10-12 Andre Vieira
* config/arm/arm.c (thumb2_legitimate_address_p): Use
VALID_MVE_MODE
when checking mve addressing modes.
(mve_vector_mem_operand): Fix the way we handle pre, post and
offset
addressing modes
.
* tree-vect-slp.c (vect_bb_vectorization_profitable_p): Adjust
call to finish_cost.
* tree-vectorizer.h (finish_cost): Change to pass new class
vec_info parameter.
On 01/10/2021 09:19, Richard Biener wrote:
On Thu, 30 Sep 2021, Andre Vieira (lists) wrote:
Hi,
That just forces
Hi,
That just forces trying the vector modes we've tried before. Though I might
need to revisit this now I think about it. I'm afraid it might be possible for
this to generate an epilogue with a vf that is not lower than that of the main
loop, but I'd need to think about this again.
Either
Hi Richi,
Thanks for the review, see below some questions.
On 21/09/2021 13:30, Richard Biener wrote:
On Fri, 17 Sep 2021, Andre Vieira (lists) wrote:
Hi all,
This patch adds the ability to define a target hook to unroll the main
vectorized loop. It also introduces --param's vect-unroll
Hi,
This patch changes the order in which we check outside and inside costs
for epilogue loops, this is to ensure that a predicated epilogue is more
likely to be picked over an unpredicated one, since it saves having to
enter a scalar epilogue loop.
gcc/ChangeLog:
*
Hi all,
This patch adds the ability to define a target hook to unroll the main
vectorized loop. It also introduces --param's vect-unroll and
vect-unroll-reductions to control this through a command-line. I found
this useful to experiment and believe can help when tuning, so I decided
to
Hi all,
This patch series enables unrolling of an unpredicated main vectorized
loop based on a target hook. The epilogue loop will have (at least) half
the VF of the main loop and can be predicated.
Andre Vieira (3):
[vect] Add main vectorized loop unrolling
[vect] Consider outside costs
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
Hi,
On 20/05/2021 11:22, Richard Biener wrote:
On Mon, 17 May 2021, Andre Vieira (lists) wrote:
Hi,
So this is my second attempt at finding a way to improve how we generate the
vector IV's and teach the vectorizer to share them between main loop and
epilogues. On IRC we discussed my idea
On 08/06/2021 16:00, Andre Simoes Dias Vieira via Gcc-patches wrote:
Hi Bin,
Thank you for the reply, I have some questions, see below.
On 07/06/2021 12:28, Bin.Cheng wrote:
On Fri, Jun 4, 2021 at 12:35 AM Andre Vieira (lists) via Gcc-patches
wrote:
Hi Andre,
I didn't look
Streams got crossed there and used the wrong subject ...
On 03/06/2021 17:34, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This RFC is motivated by the IV sharing RFC in
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569502.html and the
need to have the IVOPTS pass be able to clean up
Hi,
This RFC is motivated by the IV sharing RFC in
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569502.html and the
need to have the IVOPTS pass be able to clean up IV's shared between
multiple loops. When creating a similar problem with C code I noticed
IVOPTs treated IV's with uses
Thank you Kewen!!
I will apply this now.
BR,
Andre
On 25/05/2021 09:42, Kewen.Lin wrote:
on 2021/5/24 下午3:21, Kewen.Lin via Gcc-patches wrote:
Hi Andre,
on 2021/5/24 下午2:17, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
When vectorizing with --param vect-partial-vector-usage=1
Hi,
When vectorizing with --param vect-partial-vector-usage=1 the vectorizer
uses an unpredicated (all-true predicate for SVE) main loop and a
predicated tail loop. The way this was implemented seems to mean it
re-uses the same vector-mode for both loops, which means the tail loop
isn't an
let the
extending aarch64_load_* patterns accept both UNSPEC_LD1_SVE and
UNSPEC_PRED_X.
Is this OK for trunk?
Kind regards,
Andre Vieira
gcc/ChangeLog:
2021-05-18 Andre Vieira
* config/aarch64/iterators.md (SVE_PRED_LOAD): New iterator.
(pred_load): New int attribute.
* con
Hi,
So this is my second attempt at finding a way to improve how we generate
the vector IV's and teach the vectorizer to share them between main loop
and epilogues. On IRC we discussed my idea to use the loop's control_iv,
but that was a terrible idea and I quickly threw it in the bin. The
.
If there is a firm belief the UNSPEC_LD1_SVE will not be used for
anything I am also happy to refactor it out.
Bootstrapped and regression tested aarch64-none-linux-gnu.
Is this OK for trunk?
Kind regards,
Andre Vieira
gcc/ChangeLog:
2021-05-14 Andre Vieira
* config/aarch64/aarch64
On 05/05/2021 13:34, Richard Biener wrote:
On Wed, 5 May 2021, Andre Vieira (lists) wrote:
I tried to see what IVOPTs would make of this and it is able to analyze the
IVs but it doesn't realize (not even sure it tries) that one IV's end (loop 1)
could be used as the base for the other (loop
?
On 04/05/2021 10:56, Richard Biener wrote:
On Fri, 30 Apr 2021, Andre Vieira (lists) wrote:
Hi,
The aim of this RFC is to explore a way of cleaning up the codegen around
data_references. To be specific, I'd like to reuse the main-loop's updated
data_reference as the base_address for the e
Hi Christophe,
The series LGTM but you'll need the approval of an arm port maintainer
before committing. I only did code-review, did not try to build/run tests.
Kind regards,
Andre
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
This patch enables MVE vld4/vst4 instructions for
It would be good to also add tests for NEON as you also enable auto-vec
for it. I checked and I do think the necessary 'neon_vc' patterns exist
for 'VH', so we should be OK there.
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
This patch adds __fp16 support to the previous patch
Hi Christophe,
On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
Since MVE has a different set of vector comparison operators from
Neon, we have to update the expansion to take into account the new
ones, for instance 'NE' for which MVE does not require to use 'EQ'
with the inverted
worked out a
solution yet and does cause some minor regressions due to unfortunate
spills.
Let me know what you think and if you have ideas of how we can better
achieve this.
Kind regards,
Andre Vieira
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index
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
Hi Alex,
On 22/02/2021 10:20, Alex Coplan wrote:
For the testcase, you might want to use the one I posted most recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791#c3
which avoids the dependency on the aarch64-autovec-preference param
(which is in GCC 11 only) as this will simplify
updating allocno copy costs.
Regression tested on aarch64-linux-gnu.
Is this OK for trunk (and after a week backport to gcc-10) ?
Regards,
Andre
gcc/ChangeLog:
2021-02-19 Andre Vieira
PR rtl-optimization/98791
* ira-conflicts.c (process_regs_for_copy): Don't create allocno
Hi,
This patch prevents generating a vec_duplicate with illegal predicate.
Regression tested on aarch64-linux-gnu.
OK for trunk?
gcc/ChangeLog:
2021-02-17 Andre Vieira
PR target/98657
* config/aarch64/aarch64-sve.md: Use 'expand_vector_broadcast'
to emit vec_duplicate's
On 05/02/2021 12:47, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
As mentioned in the PR, this patch fixes up the nvectors parameter passed to
vect_get_loop_mask in vectorizable_condition.
Before the STMT_VINFO_VEC_STMTS rework we used to handle each ncopy separa
not sure it makes sense to test on
others?
Is this OK for trunk? Would you rather wait for the testcase?
gcc/ChangeLog:
2021-02-05 Andre Vieira
PR middle-end/98974
* tree-vect-stmts.c (vectorizable_condition): Fix nvectors parameter
for vect_get_loop_mask
This patch introduces a vect.mul RTX cost and decouples the vector
multiplication costing from the scalar one.
After Wilco's "AArch64: Add cost table for Cortex-A76" patch we saw a
regression in vector codegen. Reproduceable with the small test added in
this patch.
Upon further investigation
Same patch applies cleanly on gcc-8, bootstrapped
arm-none-linux-gnueabihf and ran regressions also clean.
Can I also commit it to gcc-8?
Thanks,
Andre
On 02/02/2021 17:36, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 02 February 2021 17:27
To: gcc
Hi,
This is a gcc-9 backport of the PR97528 fix that has been applied to
trunk and gcc-10.
Bootstraped on arm-linux-gnueabihf and regression tested.
OK for gcc-9 branch?
2021-02-02 Andre Vieira
Backport from mainline
2020-11-20 Jakub Jelinek
PR target/97528
* config
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
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
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
On 08/07/2020 09:04, Andre Simoes Dias Vieira wrote:
On 07/07/2020 13:43, Christophe Lyon wrote:
Hi,
On Mon, 6 Jul 2020 at 16:31, Andre Vieira (lists)
wrote:
On 30/06/2020 14:50, Andre Vieira (lists) wrote:
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56
On 30/06/2020 14:50, Andre Vieira (lists) wrote:
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56, Andre Vieira (lists)
wrote:
On 23/06/2020 21:52, Christophe Lyon wrote:
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
On 23/06/2020 13:10, Kyrylo
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56, Andre Vieira (lists)
wrote:
On 23/06/2020 21:52, Christophe Lyon wrote:
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre
On 23/06/2020 21:52, Christophe Lyon wrote:
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 22 June 2020 09:52
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH
On 23/06/2020 21:52, Christophe Lyon wrote:
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 22 June 2020 09:52
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 22 June 2020 09:52
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee saved
registers with CMSE
Hi,
As reported in bugzilla
-none-eabi.
Is this OK for trunk? (Will eventually backport to previous versions if
stable.)
Cheers,
Andre
gcc/ChangeLog:
2020-06-22 Andre Vieira
PR target/95646
* config/arm/arm.c: (cmse_nonsecure_entry_clear_before_return):
Use 'callee_saved_reg_
The 'you' here is Richi, which Richi is probably aware but maybe not the
rest of the list :')
On 09/06/2020 15:29, Andre Vieira (lists) wrote:
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant
Hi,
So this is my rework of the code you sent me, I have not included the
'permute' code you included as I can't figure out what it is meant to be
doing. Maybe something to look at later.
I have also included three tests that show it working for some simple
cases and even a nested one.
The patch applies cleanly on gcc-9 and gcc-8.
I bootstrapped this on aarch64-none-linux-gnu and tested
aarch64-none-elf for both.
Is this OK for those backports?
libgcc/ChangeLog:
2020-05-28 Andre Vieira
Backport from mainline.
2020-05-06 Kyrylo Tkachov
* config/aarch64
involving two additional register
classes was rejected in favor of the much simpler solution of
simply requiring all TImode values to be aligned.
gcc/ChangeLog:
2020-04-29 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c
Hi,
Backport of PR target/94518: Fix memmodel index in
aarch64_store_exclusive_pair
This fixes bootstrap with --enable-checking=yes,rtl for aarch64.
OK for gcc-8?
Cheers,
Andre
gcc/ChangeLog:
2020-04-28 Andre Vieira
PR target/94814
Backport from gcc-9.
2020-04-07 Kyrylo
need the overlap checks, NEON only loads from or stores to FP
registers and these can't be used in its addressing modes.
Bootstrapped arm-linux-gnueabihf with '--enable-checking=yes,rtl' for
armv7-a and amrv8-a.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-27 Andre Vieira
Add the backported functionality of -moutline-atomics for AArch64 to the
gcc-9 and gcc-8 changes.html
Validates. Is this OK?
diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index
83dd1bc010a6e4debb76790b3fe62275bf0e0657..83e57db181294110f71a5d59960fb4d3fed7be98
100644
---
it to build
even with older binutils by using .inst directive if LSE support isn't
available in the assembler.
2020-04-22 Andre Vieira
Backport from mainline.
2020-04-15 Jakub Jelinek
PR target/93053
* configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking.
* config/aarch64
On 20/04/2020 09:42, Kyrylo Tkachov wrote:
Hi Andre,
-Original Message-
From: Andre Vieira (lists)
Sent: 16 April 2020 13:24
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Sandiford
; s...@amazon.com
Subject: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics
Hi
On 16/04/2020 13:24, Andre Vieira (lists) wrote:
Hi,
This series backports all the patches and fixes regarding outline
atomics to the gcc-8 branch.
Bootstrapped the series for aarch64-linux-gnu and regression tested.
Is this OK for gcc-8?
Andre Vieira (19):
aarch64: Add early clobber
2020-04-16 Andre Vieira
Backport from mainline
2019-09-25 Richard Henderson
PR target/91833
* config/aarch64/lse-init.c: Include auto-target.h. Disable
initialization if !HAVE_SYS_AUXV_H.
* configure.ac (AC_CHECK_HEADERS): Add sys/auxv.h.
* config.in, configure
2020-04-16 Andre Vieira
Backport from mainline
2019-08-21 Prathamesh Kulkarni
PR target/90724
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
in reg if it fails aarch64_plus_operand predicate.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config
2020-04-16 Andre Vieira
Backport from mainline
2020-03-31 Jakub Jelinek
PR target/94368
* config/aarch64/constraints.md (Uph): New constraint.
* config/aarch64/atomics.md (cas_short_expected_imm): New mode attr.
(aarch64_compare_and_swap): Use it instead of n
it zero extends y
into SImode. The problem is that when the zero extended constant isn't
usable directly, it forces it into a REG, but with y_mode mode, and then
compares against y. That is wrong, because it should force it into a SImode
REG and compare that way.
2020-04-16 Andre Vieira
directive if LSE support isn't
available in the assembler.
2020-04-16 Andre Vieira
Backport from mainline
2020-04-15 Jakub Jelinek
PR target/93053
* configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking.
* config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE
2020-04-16 Andre Vieira
Backport from mainline
2020-01-17 Wilco Dijkstra
PR target/92692
* config/aarch64/atomics.md (aarch64_compare_and_swap)
Use epilogue_completed rather than reload_completed.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64
2020-04-16 Andre Vieira
Backport from mainline.
2019-09-19 Richard Henderson
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Add support
for NE comparison of TImode values.
(aarch64_emit_load_exclusive): Add support for TImode.
(aarch64_emit_store_exclusive
2020-04-16 Andre Vieira
Backport from mainline.
2019-09-19 Richard Henderson
* config/aarch64/aarch64.c (aarch64_print_operand): Allow integer
registers with %R.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index
2020-04-16 Andre Vieira
Backport from mainline
2019-09-25 Richard Henderson
PR target/91834
* config/aarch64/lse.S (LDNM): Ensure STXR output does not
overlap the inputs.
diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config/aarch64/lse.S
index
This is the libgcc part of the interface -- providing the functions.
Rationale is provided at the top of libgcc/config/aarch64/lse.S.
2020-04-16 Andre Vieira
Backport from mainline
2019-09-19 Richard Henderson
* config/aarch64/lse-init.c: New file.
* config/aarch64/lse.S
2020-04-16 Andre Vieira
Backport from mainline.
2019-09-19 Richard Henderson
* config/aarch64/aarch64 (aarch64_split_compare_and_swap):Unify
some code paths;
use aarch64_gen_compare_reg instead of open-coding.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64
2020-04-16 Andre Vieira
Backport from mainline
2019-09-19 Richard Henderson
* config/aarch64/aarch64.opt (-moutline-atomics): New.
* config/aarch64/aarch64.c (aarch64_atomic_ool_func): New.
(aarch64_ool_cas_names, aarch64_ool_swp_names): New.
(aarch64_ool_ldadd_names
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* optabs-libfuncs.c (build_libfunc_function_visibility):
New, split out from...
(build_libfunc_function): ... here.
(init_one_libfunc_visibility): New, split out from
The cas insn is a single insn, and if expanded properly need not
be split after reload. Use the proper inputs for the insn.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap):
Force
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/atomics.md (aarch64_atomic__lse):
scratch register need not be early-clobber. Document the reason
why we cannot use ST.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config
Allow zero as an input; fix constraints; avoid unnecessary split.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c (aarch64_emit_atomic_swap): Remove.
(aarch64_gen_atomic_ldop): Don't call it.
* config/aarch64
Fix constraints; avoid unnecessary split. Drop the use of the atomic_op
iterator in favor of the ATOMIC_LDOP iterator; this is simplier and more
logical for ldclr aka bic.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c
Do not zero-extend the input to the cas for subword operations;
instead, use the appropriate zero-extending compare insns.
Correct the predicates and constraints for immediate expected operand.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
gcc/ChangeLog:
2020-04-16 Andre Vieira
Backport from mainline.
2018-07-16 Ramana Radhakrishnan
* config/aarch64/atomics.md (aarch64_store_execlusive): Add
early clobber.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index
Hi,
This series backports all the patches and fixes regarding outline
atomics to the gcc-8 branch.
Bootstrapped the series for aarch64-linux-gnu and regression tested.
Is this OK for gcc-8?
Andre Vieira (19):
aarch64: Add early clobber for aarch64_store_exclusive
aarch64: Simplify LSE cas
Hi,
This patch fixes an ICE we were seeing due to a missing vec_duplicate
pattern.
Regression tested on arm-none-eabi.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-15 Andre Vieira
* config/arm/mve.md (mve_vec_duplicate): New pattern.
(V_sz_elem2): Remove unused mode
On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
This test can pass with a hard-float toolchain, provided we don't
force -mfloat-abi=softfp.
This patch removes this useless option, as well as -save-temps which
is implied by arm_v8_1m_mve_fp.
Hi Christophe,
LGTM, but you need to
On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
Since arm_mve.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide MVE
is supported while it's
On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
Several ARM/MVE tests can be compiled even if the toolchain does not
support -mfloat-abi=hard (softfp is OK).
Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using
dg-additional-options.
Hi Christophe,
I think a bunch
On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
For arm-linux-gnueabi* targets, a toolchain cannot support the
float-abi opposite to the one it has been configured for: since glibc
does not support such multilibs, we end up lacking gnu/stubs-*.h when
including stdint.h for instance.
On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
Some MVE tests explicitly test a -mfloat-abi=hard option, but we need
to check that the toolchain actually supports it (which may not be the
case for arm-linux-gnueabi* targets).
We also make use of dg-add-options arm_v8_1m_mve_fp and
NAMESPACE macro.
This patch further fixes two testisms that were brought to light by C++
testing added in this patch.
Regression tested on arm-none-eabi.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-07 Andre Vieira
* config/arm/arm_mve.h: Add C++ polymorphism and fix
preserve
Hi,
This patch fixes the passing of some pointers to builtins that expect
slightly different types of pointers. In C this didn't prove an issue,
but when compiling for C++ gcc complains.
Regression tested on arm-none-eabi.
Is this OK for trunk?
2020-04-07 Andre Vieira
* config
Hi,
This patch fixes some testisms I found when testing using -Wall/-Werror.
Is this OK for trunk?
gcc/testsuite/ChangeLog:
2020-04-07 Andre Vieira
* gcc.target/arm/mve/intrinsics/vuninitializedq_float.c: Likewise.
* gcc.target/arm/mve/intrinsics/vuninitializedq_float1.c
and
then stored in memory using scalar store pattern.
Regression tested on arm-none-eabi.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-07 Andre Vieira
* config/arm/mve.md (mve_vec_extract*): Allow memory operands
in set.
gcc/testsuite/ChangeLog:
2020-04-07 Andre Vieira
.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-07 Andre Vieira (mve_vcvtq_n_to_f_*, mve_vcvtq_n_from_f_*, mve_vqshrnbq_n_*,
mve_vqshrntq_n_*,
mve_vqshrunbq_n_s*, mve_vqshruntq_n_s*,
mve_vcvtq_m_n_from_f_*, mve_vcvtq_m_n_to_f_*,
mve_vqshrnbq_m_n_*, mve_vqrshruntq_m_n_s
On 07/04/2020 11:57, Christophe Lyon wrote:
On Tue, 7 Apr 2020 at 12:40, Andre Vieira (lists)
wrote:
Hi,
This patch fixes v[id]wdup intrinsics. They had two issues:
1) the predicated versions did not link the incoming inactive vector
parameter to the output
2) The backend didn't enforce
/2020 11:52, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 07 April 2020 11:35
To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
Subject: [PATCH][GCC][Arm]: MVE: Fix constant load pattern
Hi,
This patch fixes the constant load pattern for MVE
he
bottom part.
We can solve this in a better way, but for now this will do.
Regression tested on arm-none-eabi.
Is this OK for trunk?
2020-04-07 Andre Vieira
* config/arm/arm.d (ashldi3): Don't use lsll for constant 32-bit
shifts.
diff --git a/gcc/config/arm/arm.md b/gcc/
for trunk?
gcc/ChangeLog:
2020-04-07 Andre Vieira
* config/arm/arm_mve.h: Fix v[id]wdup intrinsics.
* config/arm/mve/md: Fix v[id]wdup patterns.
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index
e31c2e8fdc4f500bf9408d05ad86e151397627f7
on arm-none-eabi.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-07 Andre Vieira
* config/arm/arm.c (output_move_neon): Deal with label + offset
cases.
* config/arm/mve.md (*mve_mov): Handle const vectors.
gcc/testsuite/ChangeLog:
2020-04-07 Andre Vieira
* gcc.target
On 06/04/2020 16:12, Christophe Lyon via Gcc-patches wrote:
Hi,
While checking Martin's fix for PR ipa/94445, he made me realize that
the cmse-15.c testcase still fails at -Os because ICF means that we
generate
nonsecure2:
b nonsecure0
which is OK, but does not match the
Now with the zipped patch so it reaches the mailing list.
Sorry for that.
On 07/04/2020 09:57, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 07 April 2020 09:57
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][GCC][Arm]: MVE: Fix
When committing my last patch I accidentally removed -mfpu=auto from the
following tests. This puts it back.
2020-04-03 Andre Vieira
* gcc.target/arm/mve/intrinsics/mve_vector_float.c: Put
-mfpu=auto back.
* gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise
be
rather useless.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-02 Andre Vieira
* config/arm/arm_mve.h: Condition the header file on
__ARM_FEATURE_MVE.
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index
f1dcdc2153217e796c58526ba0e5be11be642234
Hi,
This patch adds an earlyclobber to the MVE instructions that require it
and were missing it. These are vrev64 and 32-bit element variants of
vcadd, vhcadd vcmul, vmull[bt] and vqdmull[bt].
Regression tested on arm-none-eabi.
Is this OK for trunk?
Cheers,
Andre
2020-03-23 Andre
Hi,
This patch series changes all MVE tests into assembly tests so we check whether
the generated assembly is syntactically correct. The first patch of the series
fixes an issue this caught where the instructions don't allow destination and
source registers to be the same.
Andre Vieira (2
MVE should
not be
using these.
This fixes regressions for gcc.dg/atomic/c11-atomic-exec-5.c
Bootstrapped and tested arm-linux-gnueabihf.
Is this OK for trunk?
gcc/ChangeLog:
2020-03-20 Andre Vieira
* config/arm/unspecs.md (UNSPEC_GET_FPSCR): Rename
Hi,
This patch fixes some testism where -mfpu=auto was missing or where we
could end up with -mfloat-abi=hard and soft on the same command-line.
Tested on arm-none-eabi.
Is this OK for trunk?
gcc/testsuite/ChangeLog:
2020-03-20 Andre Vieira
* gcc.target/arm/mve/intrinsics
.
Is this OK for trunk?
gcc/ChangeLog:
2020-03-20 Andre Vieira
* config/arm/mve.md (mve_mov): Fix R->R case.
gcc/testsuite/ChangeLog:
2020-03-** Andre Vieira
* gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c: New test.
diff --git a/gcc/config/arm/mve.md b/gcc/config/
301 - 400 of 716 matches
Mail list logo
