Re: [PATCH] arm: avoid gcc_s dependency

2025-07-15 Thread Sam James
Pierre Ossman writes: > On 14/07/2025 22:24, Sam James wrote: >> A patch rebased against trunk would also be appreciated. See >> https://gcc.gnu.org/contribute.html for the needed format. >> > > The patch applies cleanly against trunk, so nothing is needed there. > > I was hoping to get the inte

Re: [PATCH] arm: avoid gcc_s dependency

2025-07-15 Thread Pierre Ossman
On 14/07/2025 22:24, Sam James wrote: A patch rebased against trunk would also be appreciated. See https://gcc.gnu.org/contribute.html for the needed format. The patch applies cleanly against trunk, so nothing is needed there. I was hoping to get the interest of someone more familiar with gc

Re: [PATCH] arm: avoid gcc_s dependency

2025-07-15 Thread Pierre Ossman
On 14/07/2025 15:26, Kyrylo Tkachov wrote: +/* ARM EABI dummy unwinding routines. + Copyright 2014 Pierre Ossman for Cendio AB + + This file is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by the + Free Software F

Re: [PATCH] arm: avoid gcc_s dependency

2025-07-14 Thread Sam James
Kyrylo Tkachov writes: > + arm maintainers. > > Hi Pierre, > >> On 14 Jul 2025, at 14:07, Pierre Ossman wrote: >> >> Suggested fix for this issue: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 >> >> Did not get any response there, so seeing if this is a better forum for >> suggest

Re: [PATCH] arm: avoid gcc_s dependency

2025-07-14 Thread Kyrylo Tkachov
+ arm maintainers. Hi Pierre, > On 14 Jul 2025, at 14:07, Pierre Ossman wrote: > > Suggested fix for this issue: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 > > Did not get any response there, so seeing if this is a better forum for > suggested changes. > > We've been using this

[PATCH] arm: avoid gcc_s dependency

2025-07-14 Thread Pierre Ossman
Suggested fix for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 Did not get any response there, so seeing if this is a better forum for suggested changes. We've been using this patch for years without any known issues. Regards, -- Pierre Ossman Software Development

[PATCH] [arm] prevent impossible tail- long-calls with static chain [PR119430]

2025-07-10 Thread Alexandre Oliva
When a function call uses up all argument registers, and needs IP for the static chain, there isn't any call-clobbered register left for reload to assign as the sibcall target, when -mlong-calls is enabled. Use the same logic that does the job for indirect calls to prevent tail calls in this case

[PATCH] arm: Fix CMSE nonecure calls [PR 120977]

2025-07-10 Thread Christophe Lyon
As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html the operand of the call should be a mem rather than an unspec. This patch moves the unspec to an additional argument of the parallel and adjusts cmse_nonsecure_call_inline_register_clear accordingly. The scan-rtl-dump

[PATCH] arm: always enable both simd and mve builtins

2025-07-04 Thread Christophe Lyon
We get lots of error messages when compiling arm_neon.h under e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when !TARGET_HAVE_MVE. This has been the case since MVE support was introduced. This patch uses an approach similar to what we do on aarch64, but only partially since Neon i

[PATCH] [arm] require armv7 support for [PR120424] (was: Re: [PATCH, FYI?] [arm] [vxworks] require thumb2 for pr120424.C)

2025-06-19 Thread Alexandre Oliva
On Jun 19, 2025, Alexandre Oliva wrote: > Or maybe the requirements for this testcase should be stated as > arm_arch_v7? I'd have to add arm_arch_v7 to > check_effective_target_arm_arch_FUNC_ok et al, if there aren't reasons > why it's not there, but I'd be happy to do that, and use dg-add-optio

Re: [PATCH] arm: always enable both simd and mve builtins

2025-05-26 Thread Christophe Lyon
On Mon, 26 May 2025 at 18:35, Christophe Lyon wrote: > > We get lots of error messages when compiling arm_neon.h under > e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when > !TARGET_HAVE_MVE. This has been the case since MVE support was > introduced. > > This patch uses an approac

[PATCH] arm: always enable both simd and mve builtins

2025-05-26 Thread Christophe Lyon
We get lots of error messages when compiling arm_neon.h under e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when !TARGET_HAVE_MVE. This has been the case since MVE support was introduced. This patch uses an approach similar to what we do on aarch64, but only partially since Neon i

[PATCH] arm: fully validate mem_noofs_operand [PR120351]

2025-05-19 Thread Richard Earnshaw
It's not enough to just check that a memory operand is of the form mem(reg); after RA we also need to validate the register being used. The safest way to do this is to call memory_operand. PR target/120351 gcc/ChangeLog: * config/arm/predicates.md (mem_noofs_operand): Also check

[PATCH] arm: don't vectorize fmaxf() unless unsafe math opts are enabled

2025-03-26 Thread Richard Earnshaw
This test has presumably been failing since vectorization was enabled at -O2. I suspect part of the reason this wasn't picked up sooner is that the test is a hybrid execution/scan-assembler test and the execution part requires appropriate hardware. The problem is that we are vectorizing an expans

Re: [PATCH] arm: Fix REVERSIBLE_CC_MODE [PR110796...]

2025-03-13 Thread Richard Earnshaw (lists)
On 13/03/2025 08:22, Christophe Lyon wrote: > Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid > Operation" exception in presence of a NaN operand), we need to tell > the compiler it is not safe to reverse comparisons of floating-point > arguments. > > On armv8-m.main+dsp+fp (co

[PATCH] arm: Fix REVERSIBLE_CC_MODE [PR110796...]

2025-03-13 Thread Christophe Lyon
Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid Operation" exception in presence of a NaN operand), we need to tell the compiler it is not safe to reverse comparisons of floating-point arguments. On armv8-m.main+dsp+fp (cortex-m33): PASS: gcc.dg/torture/builtin-iseqsig-1.c at -

Re: [PATCH] arm: [MVE] Fix predicates for vec_cmp, vec_vcmpu and vcond_mask (PR 115439)

2025-03-11 Thread Christophe Lyon
On Mon, 10 Mar 2025 at 13:00, Richard Earnshaw (lists) wrote: > > On 16/01/2025 14:20, Christophe Lyon wrote: > > When compiling c-c++-common/vector-compare-3.c with > > -march=armv8.1-m.main+mve+fp.dp -mfloat-abi=hard -mfpu=auto > > (which enables MVE), we fail to match vcond_mask because operand

Re: [PATCH] arm: [MVE] Fix predicates for vec_cmp, vec_vcmpu and vcond_mask (PR 115439)

2025-03-10 Thread Richard Earnshaw (lists)
On 16/01/2025 14:20, Christophe Lyon wrote: > When compiling c-c++-common/vector-compare-3.c with > -march=armv8.1-m.main+mve+fp.dp -mfloat-abi=hard -mfpu=auto > (which enables MVE), we fail to match vcond_mask because operand 3 has > s_register_operand as predicate for a MVE_VPRED mode, but we try

Re: [PATCH] arm: testsuite: improve guard checks for arm_neon.h

2025-03-06 Thread Christophe Lyon
On Thu, 6 Mar 2025 at 11:03, Christophe Lyon wrote: > > On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote: > > > > The header file arm_neon.h provides the Advanced SIMD intrinsics that > > are available on armv7 or later A & R profile cores. However, they > > are not compatible with M-profile

Re: [PATCH] arm: testsuite: improve guard checks for arm_neon.h

2025-03-06 Thread Christophe Lyon
On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote: > > The header file arm_neon.h provides the Advanced SIMD intrinsics that > are available on armv7 or later A & R profile cores. However, they > are not compatible with M-profile and we also need to ensure that the > FP instructions are enabled

Re: [PATCH] arm: Handle fixed PIC register in require_pic_register (PR target/115485)

2025-03-05 Thread Richard Earnshaw (lists)
On 04/03/2025 11:01, Christophe Lyon wrote: > Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register > when extending the assert in require_pic_register. > > arm_pic_register can be set explicitly by the user > (e.g. -mpic-register=r9) or implicitly as the default value with > -fpic/

Re: [PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

2025-03-05 Thread Richard Earnshaw (lists)
On 20/02/2025 14:09, Hannes Braun wrote: > vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting > pointers to unsigned integers. These parameters should be pointers to > signed integers. > > gcc/ChangeLog: > > * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of >

[PATCH] arm: testsuite: improve guard checks for arm_neon.h

2025-03-05 Thread Richard Earnshaw
The header file arm_neon.h provides the Advanced SIMD intrinsics that are available on armv7 or later A & R profile cores. However, they are not compatible with M-profile and we also need to ensure that the FP instructions are enabled (with -mfloat-abi=softfp/hard). That leads to some complicated

[PATCH] ARM ACLE: add inline definitions for __fma and __fmaf in aarch64 and aarch32 headers

2025-03-04 Thread Ayan Shafqat
Hi GCC team, This patch introduces inline definitions for the __fma and __fmaf functions in the ARM ACLE headers for both aarch64 and arm targets. The new implementations use the built-in functions (__builtin_fma and __builtin_fmaf) to ensure proper inlining and adherence to the ARM ACLE requireme

[PATCH] arm: Handle fixed PIC register in require_pic_register (PR target/115485)

2025-03-04 Thread Christophe Lyon
Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register when extending the assert in require_pic_register. arm_pic_register can be set explicitly by the user (e.g. -mpic-register=r9) or implicitly as the default value with -fpic/-fPIC/-fPIE and -mno-pic-data-is-text-relative -mlong-ca

[PATCH] arm: Fix up REVERSE_CONDITION macro [PR119002]

2025-02-26 Thread Jakub Jelinek
Hi! The linaro CI found my PR119002 patch broke bootstrap on arm. Seems the problem is that it has incorrect REVERSE_CONDITION macro definition. All other target's REVERSE_CONDITION definitions and the default one just use the macro's arguments, while arm.h definition uses the MODE argument but us

Re: [PATCH] arm: Fix up REVERSE_CONDITION macro [PR119002]

2025-02-26 Thread Richard Earnshaw (lists)
On 26/02/2025 15:59, Jakub Jelinek wrote: > Hi! > > The linaro CI found my PR119002 patch broke bootstrap on arm. > Seems the problem is that it has incorrect REVERSE_CONDITION macro > definition. > All other target's REVERSE_CONDITION definitions and the default one > just use the macro's argumen

Re: [PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

2025-02-20 Thread Christophe Lyon
Hi, On Thu, 20 Feb 2025 at 15:18, Hannes Braun wrote: > > vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting > pointers to unsigned integers. These parameters should be pointers to > signed integers. > > gcc/ChangeLog: > > * config/arm/arm_neon.h (vld1q_s8_x3): Use in

[PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

2025-02-20 Thread Hannes Braun
vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting pointers to unsigned integers. These parameters should be pointers to signed integers. gcc/ChangeLog: * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of uint16_t. (vld1q_s16_x3): Use int16_t

Re: [PATCH] arm: Remove inner 'fix:HF/SF/DF' from fixed-point patterns (PR 117712)

2025-02-19 Thread Eric Botcazou
> Well, this adopts the same approach as the fix for PR 117525 (same > problem, but on hppa). > In that PR there's also a mention of a similar problem on Sparc, and > Konstantinos says he is working on a middle-end fix (see comment #9 in > PR117712). The problem clearly comes from the middle-end

Re: [PATCH] arm: Remove inner 'fix:HF/SF/DF' from fixed-point patterns (PR 117712)

2025-02-18 Thread Christophe Lyon
On Tue, 18 Feb 2025 at 13:49, Richard Earnshaw (lists) wrote: > > On 18/02/2025 08:37, Christophe Lyon wrote: > > As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the > > problem, like other targets do. > > > > The double-'fix' idiom was introduced in > https://gcc.gnu.org/pipermai

Re: [PATCH] arm: Remove inner 'fix:HF/SF/DF' from fixed-point patterns (PR 117712)

2025-02-18 Thread Richard Earnshaw (lists)
On 18/02/2025 08:37, Christophe Lyon wrote: > As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the > problem, like other targets do. > The double-'fix' idiom was introduced in https://gcc.gnu.org/pipermail/gcc-patches/2003-March/098380.html to address target/5985. Certainly at t

[PATCH] arm: Remove inner 'fix:HF/SF/DF' from fixed-point patterns (PR 117712)

2025-02-18 Thread Christophe Lyon
As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the problem, like other targets do. gcc/ChangeLog: PR rtl-optimization/117712 * config/arm/arm.md (fix_trunchfsi2): Remove inner fix:HF. (fix_trunchfdi2): Likewise. (fix_truncsfsi2): Remove inner fix:S

Re: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label

2025-02-17 Thread Richard Earnshaw
On 17/02/2025 13:54, Richard Earnshaw (lists) wrote: > On 17/02/2025 12:42, H.J. Lu wrote: >> On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists) >> wrote: >>> >>> On 13/02/2025 21:43, H.J. Lu wrote: Increment LABEL_NUSES when using minipool_vector_label to avoid the zero use count

Re: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label

2025-02-17 Thread Richard Earnshaw (lists)
On 17/02/2025 12:42, H.J. Lu wrote: > On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists) > wrote: >> >> On 13/02/2025 21:43, H.J. Lu wrote: >>> Increment LABEL_NUSES when using minipool_vector_label to avoid the zero >>> use count on minipool_vector_label. >>> >>> PR target/118866 >>> * conf

Re: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label

2025-02-17 Thread H.J. Lu
On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists) wrote: > > On 13/02/2025 21:43, H.J. Lu wrote: > > Increment LABEL_NUSES when using minipool_vector_label to avoid the zero > > use count on minipool_vector_label. > > > > PR target/118866 > > * config/arm/arm.cc (arm_reorg): Increment LABEL

Re: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label

2025-02-17 Thread Richard Earnshaw (lists)
On 13/02/2025 21:43, H.J. Lu wrote: > Increment LABEL_NUSES when using minipool_vector_label to avoid the zero > use count on minipool_vector_label. > > PR target/118866 > * config/arm/arm.cc (arm_reorg): Increment LABEL_NUSES when > using minipool_vector_label. > Whilst this patch isn't wrong p

[PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label

2025-02-13 Thread H.J. Lu
From: "H.J. Lu" Date: Fri, 14 Feb 2025 05:25:47 +0800 Subject: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label Increment LABEL_NUSES when using minipool_vector_label to avoid the zero use count on minipool_vector_label. PR target/118866 * config/arm/arm.cc

Re: [PATCH] arm: gimple fold aes[ed] [PR114522]

2025-02-13 Thread Richard Earnshaw (lists)
On 12/02/2025 11:01, Christophe Lyon wrote: > Almost a copy/paste from the recent aarch64 version of this patch, > this one is a bit more intrusive because it also introduces > arm_general_gimple_fold_builtin. > > With this patch, > gcc.target/arm/aes_xor_combine.c scan-assembler-not veor > passes

[PATCH] arm: gimple fold aes[ed] [PR114522]

2025-02-12 Thread Christophe Lyon
Almost a copy/paste from the recent aarch64 version of this patch, this one is a bit more intrusive because it also introduces arm_general_gimple_fold_builtin. With this patch, gcc.target/arm/aes_xor_combine.c scan-assembler-not veor passes again. gcc/ChangeLog: PR target/114522

Re: [PATCH] arm: testsuite: Adapt mve-vabs.c to improved codegen

2025-02-04 Thread Thiago Jung Bauermann
Christophe Lyon writes: > On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann > wrote: >> >> Since commit r15-491-gc290e6a0b7a9de this failure happens on on >> armv8l-linux-gnueabihf and arm-eabi: >> >> Running gcc:gcc.target/arm/simd/simd.exp ... >> gcc.target/arm/simd/mve-vabs.c: memmove foun

Re: [PATCH] arm: testsuite: Adapt mve-vabs.c to improved codegen

2025-02-03 Thread Christophe Lyon
On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann wrote: > > Since commit r15-491-gc290e6a0b7a9de this failure happens on on > armv8l-linux-gnueabihf and arm-eabi: > > Running gcc:gcc.target/arm/simd/simd.exp ... > gcc.target/arm/simd/mve-vabs.c: memmove found 0 times > FAIL: gcc.target/arm/simd/

[PATCH] arm: testsuite: Adapt mve-vabs.c to improved codegen

2025-02-02 Thread Thiago Jung Bauermann
Since commit r15-491-gc290e6a0b7a9de this failure happens on on armv8l-linux-gnueabihf and arm-eabi: Running gcc:gcc.target/arm/simd/simd.exp ... gcc.target/arm/simd/mve-vabs.c: memmove found 0 times FAIL: gcc.target/arm/simd/mve-vabs.c scan-assembler-times memmove 3 In PR PR target/116010, Andre

[PATCH] arm: Add multilib for _Float16 typeinfo for v8.1-m.main (PR 116447)

2025-01-29 Thread Christophe Lyon
Enabling 'fp' on v8.1-m.main (either via +fp, +fp.dp or +mve.dp) enables support for fp16 types (and registers _Float16 in C++). As the g++.dg/cpp23/ext-floating13.C testcase shows, this pulls typeinfo for _Float16 at link time, but a toolchain built using t-rmprofile currently relies on v8-m.main

Re: [PATCH] arm: libbacktrace: Check if the compiler supports __sync atomics

2025-01-28 Thread Richard Earnshaw (lists)
On 27/01/2025 18:07, Ian Lance Taylor wrote: > Richard Earnshaw writes: > >> Older versions of the Arm architecture lack support for __sync >> operations directly in hardware and require calls into appropriate >> operating-system hooks. But such hooks obviously don't exist in a >> freestanding e

Re: [PATCH] arm: libbacktrace: Check if the compiler supports __sync atomics

2025-01-27 Thread Ian Lance Taylor
Richard Earnshaw writes: > Older versions of the Arm architecture lack support for __sync > operations directly in hardware and require calls into appropriate > operating-system hooks. But such hooks obviously don't exist in a > freestanding environment. > > Consquently, it is incorrect to assum

[PATCH] arm: libbacktrace: Check if the compiler supports __sync atomics

2025-01-27 Thread Richard Earnshaw
Older versions of the Arm architecture lack support for __sync operations directly in hardware and require calls into appropriate operating-system hooks. But such hooks obviously don't exist in a freestanding environment. Consquently, it is incorrect to assume during configure that such functions

[PATCH] arm: [MVE] Fix predicates for vec_cmp, vec_vcmpu and vcond_mask (PR 115439)

2025-01-16 Thread Christophe Lyon
When compiling c-c++-common/vector-compare-3.c with -march=armv8.1-m.main+mve+fp.dp -mfloat-abi=hard -mfpu=auto (which enables MVE), we fail to match vcond_mask because operand 3 has s_register_operand as predicate for a MVE_VPRED mode, but we try to match: (insn 26 25 27 2 (set (reg:V4SI 137)

Re: [PATCH] arm: [MVE intrinsics] Another fix for moves of tuples (PR target/118131)

2025-01-09 Thread Richard Earnshaw (lists)
On 20/12/2024 22:53, Christophe Lyon wrote: > Commit r15-6389-g670df03e5294a3 only partially fixed support for moves > of large modes: despite the introduction of V2x* and V4x* modes in > r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support > TI, OI and XI modes, which appear for

Re: [PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-09 Thread Richard Earnshaw (lists)
On 08/01/2025 18:54, Christophe Lyon wrote: > The previous fix only worked for C, for C++ we need to add more > information to the underlying type so that > finish_class_member_access_expr accepts it. > > This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++ > mode. > > gcc/Change

[PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-08 Thread Christophe Lyon
The previous fix only worked for C, for C++ we need to add more information to the underlying type so that finish_class_member_access_expr accepts it. This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++ mode. gcc/ChangeLog: PR target/118332 * config/arm/arm-mve-

Re: [PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-07 Thread Richard Sandiford
Christophe Lyon writes: > A recent commit mistakenly changed the field name for tuples from > 'val' to '__val', but unlike SVE this name is mandated by ACLE. > > The patch simply switches back the name to 'val'. > > PR target/118332 > > gcc/ChangeLog: > > * config/arm/arm-mve-builtins.

[PATCH] arm: [MVE intrinsics] Fix tuples field name (PR 118332)

2025-01-07 Thread Christophe Lyon
A recent commit mistakenly changed the field name for tuples from 'val' to '__val', but unlike SVE this name is mandated by ACLE. The patch simply switches back the name to 'val'. PR target/118332 gcc/ChangeLog: * config/arm/arm-mve-builtins.cc (wrap_type_in_struct): Use 'val'

Re: [PATCH] arm: [MVE intrinsics] Another fix for moves of tuples (PR target/118131)

2025-01-06 Thread Christophe Lyon
ping? On Fri, 20 Dec 2024 at 23:53, Christophe Lyon wrote: > > Commit r15-6389-g670df03e5294a3 only partially fixed support for moves > of large modes: despite the introduction of V2x* and V4x* modes in > r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support > TI, OI and XI modes

[PATCH] arm: [MVE intrinsics] Another fix for moves of tuples (PR target/118131)

2024-12-20 Thread Christophe Lyon
Commit r15-6389-g670df03e5294a3 only partially fixed support for moves of large modes: despite the introduction of V2x* and V4x* modes in r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support TI, OI and XI modes, which appear for instance in gcc.dg/pr100887.c. The problem was noti

Re: [PATCH] arm: [MVE intrinsics] Fix moves of tuples (PR target/118131)

2024-12-20 Thread Richard Earnshaw (lists)
On 19/12/2024 16:45, Christophe Lyon wrote: > Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but > missed adding support for them in a few places. > > Adding them to the list in arm_attr_length_move_neon is not sufficient > since we later face another ICE where the compiler doe

[PATCH] arm: [MVE intrinsics] Fix moves of tuples (PR target/118131)

2024-12-19 Thread Christophe Lyon
Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but missed adding support for them in a few places. Adding them to the list in arm_attr_length_move_neon is not sufficient since we later face another ICE where the compiler does not know how to split move of such data. The patch

Re: [PATCH] arm: Properly escape tab, newline and semicolon in thumb1.md

2024-12-18 Thread Torbjorn SVENSSON
On 2024-12-18 14:59, Richard Earnshaw (lists) wrote: On 17/12/2024 21:01, Torbjörn SVENSSON wrote: Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85). Ok for trunk? -- Without the escape of the tab, newline and semicolon, the generated assembler output will not match the expected assm

Re: [PATCH] arm: Properly escape tab, newline and semicolon in thumb1.md

2024-12-18 Thread Richard Earnshaw (lists)
On 17/12/2024 21:01, Torbjörn SVENSSON wrote: > Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85). > > Ok for trunk? > > -- > > Without the escape of the tab, newline and semicolon, the generated > assembler output will not match the expected assmbler in the test cases. > > Fixes Linaro C

[PATCH] arm: Properly escape tab, newline and semicolon in thumb1.md

2024-12-17 Thread Torbjörn SVENSSON
Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85). Ok for trunk? -- Without the escape of the tab, newline and semicolon, the generated assembler output will not match the expected assmbler in the test cases. Fixes Linaro CI reported regression on r15-6166-gb7e11b499922 in https://linaro.

Re: [PATCH] arm,testsuite: Add -mtune=cortex-m55 to dlstp-int8x16.c

2024-12-16 Thread Richard Earnshaw (lists)
On 06/12/2024 16:09, Christophe Lyon wrote: > Like dlstp-compile-asm-1.c, this test would fail if GCC is configured > with non-default options, such as -mtune=cortex-a9. > > Force -mtune=cortex-m55 to avoid this unexpected issue. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/mve/dlstp-

[PATCH]Arm: [committed] fix bootstrap after MVE changes

2024-12-15 Thread Tamar Christina
Hi All, The recent commits for MVE on Saturday have broken armhf bootstrap due to a -Werror false positive: inlined from 'virtual rtx_def* {anonymous}::vstrq_scatter_base_impl::expand(arm_mve::function_expander&) const' at /gcc/config/arm/arm-mve-builtins-base.cc:352:17: ./genrtl.h:38:16: e

Re: [PATCH] arm: [MVE intrinsics] remove V2DF from MVE_vecs iterator

2024-12-12 Thread Richard Earnshaw (lists)
On 14/11/2024 10:42, Christophe Lyon wrote: V2DF is not supported by MVE, so remove it from the only iterator which contains it. gcc/ChangeLog: * config/arm/iterators.md (MVE_vecs): Remove V2DF. --- gcc/config/arm/iterators.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) di

Re: [PATCH] arm: [MVE intrinsics] Fix condition for vec_extract patterns

2024-12-12 Thread Richard Earnshaw (lists)
On 14/11/2024 10:41, Christophe Lyon wrote: Remove floating-point condition from mve_vec_extract_sext_internal and mve_vec_extract_zext_internal, since the MVE_2 iterator does not include any FP mode. gcc/ChangeLog: * config/arm/mve.md (mve_vec_extract_sext_internal): Fix condit

Re: [PATCH] arm: remove obsolete vcond expanders

2024-12-09 Thread Richard Earnshaw (lists)
On 09/12/2024 08:16, Richard Biener wrote: On Fri, 6 Dec 2024, Richard Earnshaw wrote: The vcond{,u} expander paterns have been declared as obsolete. Remove them from the Arm backend. OK (not sure if you were expecting approval from me ;)), the patterns are no longer exercised anywhere. My

Re: [PATCH] arm: remove obsolete vcond expanders

2024-12-09 Thread Richard Biener
On Fri, 6 Dec 2024, Richard Earnshaw wrote: > The vcond{,u} expander paterns have been declared as obsolete. Remove > them from the Arm backend. OK (not sure if you were expecting approval from me ;)), the patterns are no longer exercised anywhere. Richard. > gcc/ChangeLog: > > PR targe

[PATCH] arm: remove obsolete vcond expanders

2024-12-06 Thread Richard Earnshaw
The vcond{,u} expander paterns have been declared as obsolete. Remove them from the Arm backend. gcc/ChangeLog: PR target/114189 * config/arm/arm-protos.h (arm_expand_vcond): Delete prototype. * config/arm/arm.cc (arm_expand_vcond): Delete function. * config/arm/v

Re: [PATCH] arm,testsuite: Add -mtune=cortex-m55 to dlstp-int8x16.c

2024-12-06 Thread Richard Earnshaw (lists)
On 06/12/2024 16:09, Christophe Lyon wrote: > Like dlstp-compile-asm-1.c, this test would fail if GCC is configured > with non-default options, such as -mtune=cortex-a9. > > Force -mtune=cortex-m55 to avoid this unexpected issue. > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/mve/dlstp-

[PATCH] arm,testsuite: Add -mtune=cortex-m55 to dlstp-int8x16.c

2024-12-06 Thread Christophe Lyon
Like dlstp-compile-asm-1.c, this test would fail if GCC is configured with non-default options, such as -mtune=cortex-a9. Force -mtune=cortex-m55 to avoid this unexpected issue. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/dlstp-int8x16.c: Add -mtune=cortex-m55 --- gcc/testsuite/gcc.ta

Re: [PATCH] arm, testsuite: Add -mtune=cortex-m55 to dlstp-compile-asm-1.c test.

2024-12-06 Thread Richard Earnshaw (lists)
On 06/12/2024 10:02, Christophe Lyon wrote: > This test would fail if GCC is configured with non-default options, > such as -mtune=cortex-a9. > > This 'unexpected' scheduling makes the DLSTP optimization generate > subslr, #16 > bhi .L4 > lctp > pop {r4, r5, pc}

[PATCH] arm, testsuite: Add -mtune=cortex-m55 to dlstp-compile-asm-1.c test.

2024-12-06 Thread Christophe Lyon
This test would fail if GCC is configured with non-default options, such as -mtune=cortex-a9. This 'unexpected' scheduling makes the DLSTP optimization generate subslr, #16 bhi .L4 lctp pop {r4, r5, pc} .L4: sub ip, ip, #16 b i

Re: [PATCH] arm: Add CDE options for star-mc1 cpu

2024-12-05 Thread Richard Earnshaw (lists)
On 29/11/2024 06:02, Arvin Zhong wrote: > Hi GCC reviewers, > > The star-mc1 CPU is an Armv8-m Mainline CPU supporting ARM CDE feature. > The attached is the patch to support adding CDE options for -mcpu=star-mc1. > The patch has been built and tested on the GCC upstream with arm-none-eabi. > > I

Re: [PATCH] arm: use quotes when referring to command-line options [PR90160]

2024-12-04 Thread David Malcolm
On Wed, 2024-12-04 at 11:22 +, Richard Earnshaw (lists) wrote: > On 26/11/2024 15:51, David Malcolm wrote: > > OK for trunk? > > OK > > > (caveat: I haven't done a full test on this patch) > > Linaro's CI has, it's clean. Thanks; pushed as r15-5922-ga0ac8fa55a4749.

Re: [PATCH] arm: use quotes when referring to command-line options [PR90160]

2024-12-04 Thread Richard Earnshaw (lists)
On 26/11/2024 15:51, David Malcolm wrote: > OK for trunk? OK > (caveat: I haven't done a full test on this patch) Linaro's CI has, it's clean. R. > > gcc/ChangeLog: > PR translation/90160 > * config/arm/arm.cc (arm_option_check_internal): Use quotes in > messages that refer

Re: [PATCH] arm: Fix LDRD register overlap [PR117675]

2024-12-03 Thread Richard Earnshaw (lists)
On 03/12/2024 16:09, Wilco Dijkstra wrote: The register indexed variants of LDRD have complex register overlap constraints which makes them hard to use without using output_move_double (which can't be used for atomics as it doesn't guarantee to emit atomic LDRD/STRD when required). Add a new pr

[PATCH] arm: Fix LDRD register overlap [PR117675]

2024-12-03 Thread Wilco Dijkstra
The register indexed variants of LDRD have complex register overlap constraints which makes them hard to use without using output_move_double (which can't be used for atomics as it doesn't guarantee to emit atomic LDRD/STRD when required). Add a new predicate and constraint for plain LDRD/STRD wi

Re: [PATCH] arm: [MVE intrinsics] Avoid warnings when floating-point is not supported [PR 117814]

2024-12-02 Thread Christophe Lyon
On Mon, 2 Dec 2024 at 12:44, Richard Earnshaw (lists) wrote: > > On 02/12/2024 11:21, Christophe Lyon wrote: > > If the target does not support floating-point, we register FP vector > > types as 'void' (see register_vector_type). > > > > The leads to warnings about 'pure attribute on function retu

Re: [PATCH] arm: [MVE intrinsics] Avoid warnings when floating-point is not supported [PR 117814]

2024-12-02 Thread Richard Earnshaw (lists)
On 02/12/2024 11:21, Christophe Lyon wrote: > If the target does not support floating-point, we register FP vector > types as 'void' (see register_vector_type). > > The leads to warnings about 'pure attribute on function returning > void' when we declare the various load intrinsics because their >

[PATCH] arm: [MVE intrinsics] Avoid warnings when floating-point is not supported [PR 117814]

2024-12-02 Thread Christophe Lyon
If the target does not support floating-point, we register FP vector types as 'void' (see register_vector_type). The leads to warnings about 'pure attribute on function returning void' when we declare the various load intrinsics because their call_properties say CP_READ_MEMORY (thus giving them th

Re: [PATCH] arm, testsuite: Adjust Arm tests after c23 changes

2024-11-29 Thread Christophe Lyon
FTR this patch is superseded by Andre's patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670378.html On Thu, 28 Nov 2024 at 11:12, Christophe Lyon wrote: > > After the recent c23, GCC complains because the testcase calls f() > with a parameter whereas the prototype has none. > >

Re: [PATCH] arm, mve: Do not DLSTP transform loops if VCTP is not first

2024-11-29 Thread Andre Vieira (lists)
Hi Christophe, On 28/11/2024 17:00, Christophe Lyon wrote: Hi Andre, Thanks, the patch LGTM except a minor nit: /* Using a VPR that gets re-generated within the loop. */ -void test10 (int32_t *a, int32_t *b, int32_t *c, int n) +void test10a (int32_t *a, int32_t *b, int32_t *c, int n) [...]

[PATCH] arm: Add CDE options for star-mc1 cpu

2024-11-28 Thread Arvin Zhong
Hi GCC reviewers, The star-mc1 CPU is an Armv8-m Mainline CPU supporting ARM CDE feature. The attached is the patch to support adding CDE options for -mcpu=star-mc1. The patch has been built and tested on the GCC upstream with arm-none-eabi. Is it OK for trunk? Thanks. Best Regards, Arvin Zhong

Re: [PATCH] arm, mve: Do not DLSTP transform loops if VCTP is not first

2024-11-28 Thread Christophe Lyon
Hi Andre, On Thu, 28 Nov 2024 at 17:37, Andre Vieira wrote: > > Hi, > > This rejects any loops where any predicated instruction comes before the vctp > that generates the loop predicate. Even though this is not a requirement for > dlstp transformation we have found potential issues where you can

[PATCH] arm, mve: Do not DLSTP transform loops if VCTP is not first

2024-11-28 Thread Andre Vieira
Hi, This rejects any loops where any predicated instruction comes before the vctp that generates the loop predicate. Even though this is not a requirement for dlstp transformation we have found potential issues where you can end up with a wrong transformation, so it is safer to reject such loops.

Re: [PATCH] arm: [MVE intrinsics] fix vctpq intrinsic implementation [PR target/117814]

2024-11-28 Thread Christophe Lyon
On Thu, 28 Nov 2024 at 15:13, Andre Vieira (lists) wrote: > > Hi Christophe, > > On 28/11/2024 10:22, Christophe Lyon wrote: > > The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based > > on the input value, but also constrained by a VPT block (if present), > > or if used within a D

Re: [PATCH] arm: [MVE intrinsics] fix vctpq intrinsic implementation [PR target/117814]

2024-11-28 Thread Andre Vieira (lists)
Hi Christophe, On 28/11/2024 10:22, Christophe Lyon wrote: The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based on the input value, but also constrained by a VPT block (if present), or if used within a DLSTP/LETP loop. Therefore we need to inform the compiler that this intrinsi

[PATCH] arm: [MVE intrinsics] fix vctpq intrinsic implementation [PR target/117814]

2024-11-28 Thread Christophe Lyon
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based on the input value, but also constrained by a VPT block (if present), or if used within a DLSTP/LETP loop. Therefore we need to inform the compiler that this intrinsic reads the FPCXT register, otherwise it could make incorrect

[PATCH] arm, testsuite: Adjust Arm tests after c23 changes

2024-11-28 Thread Christophe Lyon
After the recent c23, GCC complains because the testcase calls f() with a parameter whereas the prototype has none. gcc/testsuite/ChangeLog * gcc.target/arm/mve/dlstp-loop-form.c: Fix f() prototype. --- gcc/testsuite/gcc.target/arm/mve/dlstp-loop-form.c | 2 +- 1 file changed, 1 i

[PATCH] arm: use quotes when referring to command-line options [PR90160]

2024-11-26 Thread David Malcolm
OK for trunk? (caveat: I haven't done a full test on this patch) gcc/ChangeLog: PR translation/90160 * config/arm/arm.cc (arm_option_check_internal): Use quotes in messages that refer to command-line options. Tweak wording. Signed-off-by: David Malcolm --- gcc/config/a

[PATCH] arm, mve: Fix arm_mve_dlstp_check_dec_counter's use of single_pred

2024-11-20 Thread Andre Vieira (lists)
Hi, Looks like single_pred ICEs if the basic-block does not have a single predecessor rather than return NULL, which was what this snippet of code relied on. This feels like borderline obvious to me as a fix, but I thought I'd get it checked by one more person. Call 'single_pred_p' before 's

Re: [PATCH] arm, mve: Fix arm_mve_dlstp_check_dec_counter's use of single_pred

2024-11-20 Thread Christophe Lyon
On Tue, 19 Nov 2024 at 15:00, Andre Vieira (lists) wrote: > > Hi, > > Looks like single_pred ICEs if the basic-block does not have a single > predecessor rather than return NULL, which was what this snippet of code > relied on. > This feels like borderline obvious to me as a fix, but I thought I'd

[PATCH] arm: [MVE intrinsics] remove V2DF from MVE_vecs iterator

2024-11-14 Thread Christophe Lyon
V2DF is not supported by MVE, so remove it from the only iterator which contains it. gcc/ChangeLog: * config/arm/iterators.md (MVE_vecs): Remove V2DF. --- gcc/config/arm/iterators.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/arm/iterators.md b/gcc/con

[PATCH] arm: [MVE intrinsics] Fix condition for vec_extract patterns

2024-11-14 Thread Christophe Lyon
Remove floating-point condition from mve_vec_extract_sext_internal and mve_vec_extract_zext_internal, since the MVE_2 iterator does not include any FP mode. gcc/ChangeLog: * config/arm/mve.md (mve_vec_extract_sext_internal): Fix condition. (mve_vec_extract_zext_internal):

Re: [PATCH] arm: Don't ICE on arm_mve.h pragma without MVE types [PR117408]

2024-11-07 Thread Christophe Lyon
Hi, On Fri, 1 Nov 2024 at 22:10, Torbjörn SVENSSON wrote: > > There is one more problem, that this patch does not address, and that is > that there are warnings like below, but I do not know what's causing them. > > .../gcc/testsuite/gcc.target/arm/pr117408-1.c:8:9: warning: 'pure' attribute >

[PATCH] arm: Don't ICE on arm_mve.h pragma without MVE types [PR117408]

2024-11-01 Thread Torbjörn SVENSSON
There is one more problem, that this patch does not address, and that is that there are warnings like below, but I do not know what's causing them. .../gcc/testsuite/gcc.target/arm/pr117408-1.c:8:9: warning: 'pure' attribute on function returning 'void' [-Wattributes] .../gcc/testsuite/gcc.target

[committed] [PATCH] arm: [MVE intrinsics] Remove unused builtins qualifiers

2024-10-30 Thread Christophe Lyon
After the re-implementation of MVE vld/vst intrinsics, a few builtins qualifiers became useless. This patch removes them to restore bootstrap (otherwise the build fails because of 'defined but not used' errors. gcc/ChangeLog: * config/arm/arm-builtins.cc (STRS_QUALIFIERS): Delete.

Re: [PATCH] arm: Support -mfdpic for more targets

2024-10-25 Thread Richard Earnshaw (lists)
On 24/02/2024 03:33, Fangrui Song wrote: > From: Fangrui Song > > Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c > -mfdpic does not pass --fdpic to gas. This is an unnecessary > restriction. Just define the ASM_SPEC in bpabi.h. > > Additionally, use armelf[b]_linux_fdp

Re: [RFC PATCH] ARM: thumb1: fix bad code emitted when HI_REGS involved

2024-10-04 Thread Siarhei Volkau
пт, 4 окт. 2024 г. в 19:07, Christophe Lyon : > > On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote: > > > > Hello, > > > > пт, 4 окт. 2024 г. в 16:48, Christophe Lyon : > > > > > > Hi! > > > > > > > > > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote: > > > > > > > > ping > > > > > > > > чт,

Re: [RFC PATCH] ARM: thumb1: fix bad code emitted when HI_REGS involved

2024-10-04 Thread Christophe Lyon
On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote: > > Hello, > > пт, 4 окт. 2024 г. в 16:48, Christophe Lyon : > > > > Hi! > > > > > > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote: > > > > > > ping > > > > > > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau : > > > > > > > > This patch deals wi

Re: [RFC PATCH] ARM: thumb1: fix bad code emitted when HI_REGS involved

2024-10-04 Thread Siarhei Volkau
Hello, пт, 4 окт. 2024 г. в 16:48, Christophe Lyon : > > Hi! > > > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote: > > > > ping > > > > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau : > > > > > > This patch deals with consequences but not the root cause though. > > > > > > There are 5 cases whic

  1   2   3   4   5   6   7   8   9   10   >