On Wed, Nov 10, 2021 at 4:34 PM Kyrylo Tkachov via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi Christophe
>
> > -Original Message-
> > From: Gcc-patches > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> > Lyon via Gcc-
Hi,
On Tue, Nov 9, 2021 at 12:36 PM Przemyslaw Wirkus via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> > > > -Original Message-
> > > > From: Przemyslaw Wirkus
> > > > Sent: 18 October 2021 10:37
> > > > To: gcc-patches@gcc.gnu.org
> > > > Cc: Richard Earnshaw ; Ramana
> > > > Radhakr
ibraries.
> It might be that we can deal with v9-a by just mapping it to the v8-a
> equivalents. That would then avoid the need for an updated assembler,
> and reduce the build time and install footprint.
>
> R.
>
>
> On 16/11/2021 08:03, Christophe Lyon via Gcc-patches wro
Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
and since the testcase forces -march=armv8-m.base, we need to check
whether this option is actually supported.
Using dg-add-options arm_arch_v8m_base ensure that we pass -mthumb as
needed too.
2021-05-19 Christophe Lyon
On Tue, 18 May 2021 at 09:42, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As mentioned earlier, spaceship_replacement didn't optimize partial_ordering
> >= 0 comparisons, because the possible values are -1, 0, 1, 2 and the
> >= comparison is implemented as (res & 1) == res to choose the 0 and
The toolchain provided by ST for stm32 has had support for
__FILENAME__ for a while, but clang/llvm has recently implemented
support for __FILE_NAME__, so it seems better to use the same macro
name in GCC.
It happens that the ST patch is similar to the one proposed in PR
c/42579.
Given these inpu
On Wed, 19 May 2021 at 13:13, Richard Biener wrote:
>
> On Wed, 19 May 2021, Jakub Jelinek wrote:
>
> > On Wed, May 19, 2021 at 11:09:19AM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Wed, May 19, 2021 at 10:15:53AM +0200, Christophe Lyon via Gcc-patch
ote:
> > > > On Wed, May 19, 2021 at 10:15:53AM +0200, Christophe Lyon via
> > > > Gcc-patches wrote:
> > > > > After this update, the test fails on arm and aarch64: according to the
> > > > > logs, the optimization is
On Wed, 19 May 2021 at 16:40, Richard Earnshaw
wrote:
>
>
>
> On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote:
> > Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
> > and since the testcase forces -march=armv8-m.base, we need to check
&g
On Wed, 19 May 2021 at 16:50, Joseph Myers wrote:
>
> This patch is missing documentation (in cpp.texi) and tests for the value
> of the macro.
>
Indeed. How about this new version?
Thanks
Christophe
> --
> Joseph S. Myers
> jos...@codesourcery.com
commit d0e79f75dc3723231609f24e2840ac5858a652
On Thu, 20 May 2021 at 10:52, Kewen.Lin via Gcc-patches
wrote:
>
> on 2021/5/19 下午6:01, Richard Biener wrote:
> > On Wed, May 19, 2021 at 11:47 AM Kewen.Lin wrote:
> >>
> >> Hi Richi,
> >>
> >> on 2021/5/19 下午4:15, Richard Biener wrote:
> >>> On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
> >>
ping?
On Mon, 17 May 2021 at 11:55, Christophe Lyon
wrote:
>
> ping?
>
> On Fri, 30 Apr 2021 at 16:09, Christophe Lyon
> wrote:
> >
> > 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 r
> > > 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.
> > >
> >
> > Hi Andre,
> >
> > Thanks for the comments!
> >
> > > Kind re
This patch adds support for the reduc_plus_scal optab with MVE, which
maps to the vaddv instruction.
It moves the reduc_plus_scal_ expander from neon.md to
vec-common.md and adds support for MVE to it.
Since vaddv uses a 32-bits accumulator, we have to truncate it's
result.
For instance:
int32_t
On Wed, 26 May 2021 at 11:32, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > This patch adds support for the reduc_plus_scal optab with MVE, which
> > maps to the vaddv instruction.
> >
> > It moves the reduc_plus_scal_ expander from neon.md to
> > vec-common.md and adds support for MVE
Hi,
On Tue, 25 May 2021 at 18:17, Aldy Hernandez via Gcc-patches
wrote:
>
> Adjustments per discussion.
>
> OK pending tests?
>
The xfail removal causes failures on 32 bits platforms (eg arm, or
aarch64 with -mabi=ilp32):
FAIL: gcc.dg/Wstringop-overflow-55.c pr? (test for warnings, line 86)
This patch adds support for auto-vectorization of absolute value
computation using vabs.
We use a similar pattern to what is used in neon.md and extend the
existing neg2 expander to match both 'neg' and 'abs'. This
implies renaming the existing abs2 define_insn in neon.md to
avoid a clash with th
At the moment I sent that patch I remembered that Victor is also
working on vabs, so sorry if this conflicts with his work.
On Thu, 27 May 2021 at 13:21, Christophe Lyon
wrote:
>
> This patch adds support for auto-vectorization of absolute value
> computation using vabs.
>
> We use a similar pat
On Sat, 29 May 2021 at 10:03, Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, May 28, 2021 at 12:59:20AM +0200, Tobias Burnus wrote:
> > * gfortran.dg/gomp/depend-iterator-1.f90: New test.
> > * gfortran.dg/gomp/depend-iterator-2.f90: New test.
>
> Something I've missed during the rev
This patch adds support for auto-vectorization of average value
computation using vhadd or vrhadd, for both MVE and Neon.
The patch adds the needed [u]avg3_[floor|ceil] patterns to
vec-common.md, I'm not sure how to factorize them without introducing
an unspec iterator?
It also adds tests for 'fl
On Tue, 1 Jun 2021 at 08:06, apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> This is the first of series of patches to simplify phi-opt
> to use match and simplify in many cases. This simplification
> will more things to optimize.
>
> This is what Richard requested in
> https://gcc
gt; > >> 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:
> > >>>>>
>
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, C
On Thu, 3 Jun 2021 at 00:31, Przemyslaw Wirkus via Gcc-patches
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Vladimir Makarov
> > Sent: 31 May 2021 16:52
> > To: Przemyslaw Wirkus ; Richard Biener
> >
> > Cc: gcc-patches@gcc.gnu.org; ja...@redhat.com; ni...@redhat.com;
> > Richard Ea
On Thu, 3 Jun 2021 at 10:54, Przemyslaw Wirkus
wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 03 June 2021 09:45
> > To: Przemyslaw Wirkus
> > Cc: Vladimir Makarov ; ja...@redhat.com; Richard
> > Earnshaw ; Richard Biener
> > ; gcc-patches@gcc.gnu.org; Ramana Rad
On Fri, 4 Jun 2021 at 09:27, Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> As mentioned in PR, for the following test-case:
>
> #include
>
> bfloat16x4_t f1 (bfloat16_t a)
> {
> return vdup_n_bf16 (a);
> }
>
> bfloat16x4_t f2 (bfloat16_t a)
> {
> return (bfloat16x4_t) {a, a, a, a};
> }
On Wed, 2 Jun 2021 at 20:19, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > This patch adds support for auto-vectorization of average value
> > computation using vhadd or vrhadd, for both MVE and Neon.
> >
> > The patch adds the needed [u]avg3_[floor|ceil] patterns to
> > vec-common.md,
This patch adds support for auto-vectorization of clz for MVE.
It does so by removing the unspec from mve_vclzq_ and uses
'clz' instead. It moves to neon_vclz expander from neon.md to
vec-common.md and renames it into the standard name clz2.
2021-06-03 Christophe Lyon
gcc/
* c
This patch adds vec_unpack_hi_, vec_unpack_lo_,
vec_pack_trunc_ patterns for MVE.
It does so by moving the unpack patterns from neon.md to
vec-common.md, while adding them support for MVE. The pack expander is
derived from the Neon one (which in turn is renamed into
neon_quad_vec_pack_trunc_).
Th
This patch fixes a problem in arm_expand_vcond() where the result
would be a vector of 0 or 1 instead of operand 1 or 2. The
mve-vcmp-f32-2.c testcase is an update from mve-vcmp-f32.c using a
conditional with 2.0f and 3.0f constants to help scan-assembler-times.
2021-06-09 Christophe Lyon
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type. The fix is
to transfer this value to VPR.P0 by comparing operand 3 with a vector
of constant 1 of the sa
On Tue, 8 Jun 2021 at 21:34, David Malcolm via Gcc-patches
wrote:
>
> This patch verifies the previous fix for bitfield sizes by implementing
> enough support for bitfields in the analyzer to get the test cases to pass.
>
> The patch implements support in the analyzer for reading from a
> BIT_FIEL
Hi,
On Wed, 9 Jun 2021 at 01:05, Thomas Rodgers via Gcc-patches
wrote:
>
> Tested x86_64-pc-linux-gnu, committed to master, backported to
> releases/gcc-11.
>
> On Tue, Jun 8, 2021 at 8:44 AM Jonathan Wakely wrote:
>
> > On Tue, 8 Jun 2021 at 01:29, Thomas Rodgers wrote:
> >
> >> This time with
On Tue, 8 Jun 2021 at 13:50, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Wed, 2 Jun 2021 at 20:19, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > This patch adds support for auto-vectorization of average value
> >> > computation using vhadd or vrhadd, for
On Tue, 8 Jun 2021 at 13:58, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > This patch adds support for auto-vectorization of clz for MVE.
> >
> > It does so by removing the unspec from mve_vclzq_ and uses
> > 'clz' instead. It moves to neon_vclz expander from neon.md to
> > vec-common.
On Wed, 9 Jun 2021 at 17:39, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > This patch adds support for auto-vectorization of average value
> > computation using vhadd or vrhadd, for both MVE and Neon.
> >
> > The patch adds the needed [u]avg3_[floor|ceil] patterns to
> > vec-common.md,
On Wed, 9 Jun 2021 at 18:56, Alex Coplan via Gcc-patches
wrote:
>
> Hi Richi,
>
> On 09/06/2021 14:42, Richard Biener via Gcc-patches wrote:
> > On Mon, May 31, 2021 at 5:00 PM Richard Biener wrote:
> > >
> > > This makes SLP discovery handle associatable (including mixed
> > > plus/minus) chains
On Tue, 8 Jun 2021 at 14:10, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > This patch adds vec_unpack_hi_, vec_unpack_lo_,
> > vec_pack_trunc_ patterns for MVE.
> >
> > It does so by moving the unpack patterns from neon.md to
> > vec-common.md, while adding them support for MVE. The pa
On Thu, 10 Jun 2021 at 11:50, Christophe Lyon
wrote:
>
> On Tue, 8 Jun 2021 at 14:10, Richard Sandiford
> wrote:
> >
> > Christophe Lyon writes:
> > > This patch adds vec_unpack_hi_, vec_unpack_lo_,
> > > vec_pack_trunc_ patterns for MVE.
> > >
> > > It does so by moving the unpack patterns from
On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
wrote:
>
> This patch removes the uses of %K from error() calls in the aarch64
> and arm back ends. I tested this change only by building a cross-
> compiler but I can't easily run the tests so I'd appreciate some help
> validating it. T
On Fri, 11 Jun 2021 at 11:38, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Tue, 8 Jun 2021 at 14:10, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > This patch adds vec_unpack_hi_, vec_unpack_lo_,
> >> > vec_pack_trunc_ patterns for MVE.
> >> >
> >> > It doe
On Fri, 11 Jun 2021 at 09:53, Christophe Lyon
wrote:
>
> On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
> wrote:
> >
> > This patch removes the uses of %K from error() calls in the aarch64
> > and arm back ends. I tested this change only by building a cross-
> > compiler but I can't
On Fri, 11 Jun 2021 at 12:20, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > In the meantime, I tried to make some progress, and looked at how
> > things work on aarch64.
> >
> > This led me to define (in mve.md):
> >
> > (define_insn "@mve_vec_pack_trunc_lo_"
> > [(set (match_operand:
On 28/09/2021 15:30, Christophe LYON via Gcc-patches wrote:
On 28/09/2021 13:14, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: 07 September 2021 10:15
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 03/13] arm: Add test
On 28/09/2021 15:32, Christophe LYON via Gcc-patches wrote:
On 28/09/2021 13:18, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Gcc-patches On Behalf Of Christophe
LYON via Gcc-patches
Sent: 08 September 2021 08:49
To: Richard Earnshaw ; gcc-
patc...@gcc.gnu.org
This is v2 of this patch series, addressing the comments I received.
The changes v1 -> v2 are:
- Patch 3: added an executable test, and updated
check_effective_target_arm_mve_hw
- Patch 4: split into patch 4 and patch 14 (to keep numbering the same
for the other patches)
- Patch 5: updated arm
This patch mainly adds Neon tests similar to existing MVE ones,
to make sure we do not break Neon when fixing MVE.
mve-vcmp-f32-2.c is similar to mve-vcmp-f32.c but uses a conditional
with 2.0f and 3.0f constants to help scan-assembler-times.
2021-10-13 Christophe Lyon
gcc/testsuite/
These tests currently trigger an ICE which is fixed later in the patch
series.
The pr100757*.c testcases are derived from
gcc.c-torture/compile/20160205-1.c, forcing the use of MVE, and using
various types and return values different from 0 and 1 to avoid
commonalization with boolean masks. In ad
These tests are derived from the one provided in the PR: there is a
compile-only test because I did not have access to anything that could
execute MVE code until recently.
I have been able to add an executable test since QEMU supports MVE.
Instead of adding arm_v8_1m_mve_hw, I update arm_mve_hw so
At some point during the development of this patch series, it appeared
that in some cases the register allocator wants “VPR or general”
rather than “VPR or general or FP” (which is the same thing as
ALL_REGS). The series does not seem to require this anymore, but it
seems to be a good thing to do
VPR_REG is the only register in its class, so it should be handled by
TARGET_CLASS_LIKELY_SPILLED_P, which is achieved by calling
default_class_likely_spilled_p. No test fails without this patch, but
it seems it should be implemented.
2021-10-13 Christophe Lyon
gcc/
* config/a
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
2021-10-13 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vmvnq_n_): Use V_elem mode
for operand 1.
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
ind
This patch implements support for vectors of booleans to support MVE
predicates, instead of HImode. Since the ABI mandates pred16_t (aka
uint16_t) to represent predicates in intrinsics prototypes, we
introduce a new "predicate" type qualifier so that we can map relevant
builtins HImode arguments a
We make use of qualifier_predicate to describe MVE builtins
prototypes, restricting to auto-vectorizable vcmp* and vpsel builtins,
as they are exercised by the tests added earlier in the series.
Special handling is needed for mve_vpselq because it has a v2di
variant, which has no natural VPR.P0 re
On Mon, Oct 11, 2021 at 4:10 PM Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Christophe Lyon via Gcc-patches writes:
> > The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
> > iterator instead of HI in mve_vmvnq_n_.
> >
>
The problem in this PR is that we call VPSEL with a mask of vector
type instead of HImode. This happens because operand 3 in vcond_mask
is the pre-computed vector comparison and has vector type.
This patch fixes it by implementing TARGET_VECTORIZE_GET_MASK_MODE,
returning the appropriate VxBI mode
This is mostly a mechanical change, only tested by the intrinsics
expansion tests.
2021-10-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (BINOP_UNONE_NONE_NONE_QUALIFIERS):
Delete.
(TERNOP_UNONE_NONE_NONE_U
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
For v2di instructions, we use the V8BI mode for predicates.
2021-10-13 Christophe Lyon
gcc/
PR target/100757
PR target/101325
* config/arm/arm-builtins.c (STRSBS_P_QUALI
This patch covers a few non-load/store builtins where we do not use
the iterator and thus we cannot use .
We need to update the expected code in cde-mve-full-assembly.c because
we now use mve_movv16qi instead of movhi to generate the vmsr
instruction.
2021-10-13 Christophe Lyon
gcc/
VPR_REG should be part of ALL_REGS, this patch fixes this omission.
2021-10-13 Christophe Lyon
gcc/
* config/arm/arm.h (REG_CLASS_CONTENTS): Add VPR_REG to ALL_REGS.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index eae1b1cd0fb..fab39d05916 100644
--- a/gcc/config
On 14/10/2021 14:21, Aldy Hernandez via Gcc-patches wrote:
In the path solver, when requesting the range of an SSA for which we
know nothing, we ask the ranger for the range incoming to the path.
We do this by asking for all the incoming ranges to the path entry
block and unioning them.
The pr
On 15/10/2021 17:08, Richard Sandiford wrote:
Christophe Lyon via Gcc-patches writes:
This patch covers a few builtins where we do not use the
iterator and thus we cannot use .
For v2di instructions, we use the V8BI mode for predicates.
Why V8BI though, when VPRED uses HI?
Hmm.. I used
Hi,
On Tue, Oct 19, 2021 at 11:03 AM liuhongt via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> updated patch:
> 1. Add documents in doc/sourcebuild.texi (Effective-Target Keywords).
> 2. Reduce -novec.c testcases to contain only new failed parted which
> is caused by O2 vectorization.
>
On 20/10/2021 12:16, Richard Biener via Gcc-patches wrote:
On Wed, 20 Oct 2021, Andre Vieira (lists) wrote:
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 typ
On Tue, 6 Jul 2021 at 11:28, Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Prathamesh Kulkarni
> > Sent: 06 July 2021 10:25
> > To: Kyrylo Tkachov
> > Cc: Christophe LYON ; gcc Patches > patc...@gcc.gnu.org>
> > Subject: Re: [ARM] PR98435: Missed optimizat
On Wed, Jul 7, 2021 at 11:38 AM Andreas Schwab
wrote:
> This broke bootstrap on aarch64.
>
>
This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
Christophe
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA A
ping?
On Wed, Jun 30, 2021 at 3:58 PM Christophe LYON via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> I've noticed that overriding cpu/arch flags when running the testsuite
> can cause this test to fail rather than being skipped because of
> incompatible flags combination
On Thu, 8 Jul 2021 at 12:42, Andreas Schwab wrote:
>
> On Jul 07 2021, Marek Polacek via Gcc-patches wrote:
>
> > On Wed, Jul 07, 2021 at 02:38:11PM -0600, Martin Sebor via Gcc-patches
> > wrote:
> >> I certainly will. Pushed in r12-2132.
> >
> > I think this patch breaks bootstrap on x86_64:
>
Ping?
Le ven. 2 juil. 2021 à 10:53, Christophe Lyon
a écrit :
> Hi,
>
> On Wed, 9 Jun 2021 at 17:04, Richard Sandiford
> wrote:
> >
> > Christophe Lyon writes:
> > > The problem in this PR is that we call VPSEL with a mask of vector
> > > type instead of HImode. This happens because operand 3
Hi,
On Sat, Jul 10, 2021 at 1:11 AM Martin Sebor via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> The attached tweak avoids the new -Warray-bounds instances when
> building libatomic for arm. Christophe confirms it resolves
> the problem (thank you!)
>
> As we have discussed, the main goal of
Hi Tamar,
On Tue, May 25, 2021 at 5:41 PM Tamar Christina via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi All,
>
> The RTL Generated from dot_prod is invalid as operand3 cannot
> be
> written to, it's a normal input. For the expand it's just another operand
> but the caller does not expe
On Mon, Jul 12, 2021 at 5:31 PM Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Jonathan Wright writes:
> > Hi,
> >
> > Version 2 of this patch adds more code generation tests to show the
> > benefit of this RTL simplification as well as adding a new helper
> function
> > 'r
Hi Prathamesh,
On Mon, Jul 5, 2021 at 11:25 AM Kyrylo Tkachov via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> > -Original Message-
> > From: Prathamesh Kulkarni
> > Sent: 05 July 2021 10:18
> > To: gcc Patches ; Kyrylo Tkachov
> >
> > Subject: [ARM] PR66791: Replace builtins for
Hi,
On Tue, Jul 13, 2021 at 2:09 PM Richard Biener wrote:
> The following adds support for re-using the vector reduction def
> from the main loop in vectorized epilogue loops on architectures
> which use different vector sizes for the epilogue. That's only
> x86 as far as I am aware.
>
> vect
This is a followup to Srinath's recent patch: the newly added test is
failing e.g. on arm-linux-gnueabihf without R/M profile multilibs.
It is also failing on arm-eabi with R/M profile multilibs if the
execution engine does not support v8.1-M instructions.
The patch avoids this by adding check_e
On Thu, Jul 15, 2021 at 2:34 PM Richard Biener wrote:
> On Thu, 15 Jul 2021, Christophe Lyon wrote:
>
> > Hi,
> >
> >
> >
> > On Tue, Jul 13, 2021 at 2:09 PM Richard Biener
> wrote:
> >
> > > The following adds support for re-using the vector reduction def
> > > from the main loop in vectorized
This test fails when forcing an -mcpu option incompatible with
-march=armv8.2-a+i8mm.
This patch adds the missing arm_v8_2a_i8mm_ok effective-target, as
well as the associated dg-add-options arm_v8_2a_i8mm.
2021-07-15 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/simd/vusdot
This patch removes this recently-introduced effective-target, as it
looks like a typo and duplicate for arm_v8_2a_i8mm_ok (imm8 vs i8mm),
and it is not used.
2021-07-15 Christophe Lyon
gcc/testsuite/
* lib/target-supports.exp (arm_v8_2a_imm8_neon_ok_nocache):
Delete.
--
On 16/07/2021 16:06, Richard Sandiford via Gcc-patches wrote:
Hi,
Sorry for the slow review. I'd initially held off from reviewing
because it sounded like you were trying to treat predicates as
MODE_VECTOR_BOOL instead. Is that right? If so, how did that go?
Yes, that's part of PR 101325
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
> >
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_insn): Print fa
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-tim
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/s
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(+)
cr
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
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/si
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 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-v
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*): Cal
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): Lik
After removing the signed and unsigned suffixes in the previous
patches, we can now factorize the vcmp* patterns: there is no longer
an asymmetry where operators do not have the same set of signed and
unsigned variants.
The will make maintenance easier.
MVE has a different set of vector compariso
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.
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.
* config/arm/arm_mve_bui
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
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 condition.
Conversely, Neon supports comparisons with #0, MVE does not.
For:
ty
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 .
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 .
ping?
On Thu, 22 Apr 2021 at 15:32, Christophe Lyon
wrote:
>
> The test requires an FPU, so use -march=armv7-a+fp -mfpu=auto instead
> of -march=armv7-a.
>
> We also remove dg-require-effective-target arm_fp_ok, but keep
> dg-add-options arm_fp: this enables the test to pass on arm-eabi
> configu
ping?
On Thu, 22 Apr 2021 at 09:01, Christophe Lyon
wrote:
>
> arm.h has had this error message since 1997, and was never updated to
> take softfp into account. Anyway, it seems it was useful long ago, but
> it is no longer needed since option parsing has been improved:
> -mfloat-abi is handled v
ping?
On Wed, 21 Apr 2021 at 22:48, Christophe Lyon
wrote:
>
> The acle/saturation.c test uses __[su]sat() and
> __saturation_occurred() intrinsics but __[su]sat() are defined in
> acle.h if __ARM_FEATURE_SAT true, while __saturation_occurred()
> depends on __ARM_FEATURE_QBIT.
>
> QBIT is a v5te
401 - 500 of 982 matches
Mail list logo
