On 09/01/2025 23:04, Richard Sandiford wrote:
+ gcc_assert (imm != 0);
The constraints do allow 0, so I'm not sure this assert is safe.
Certainly we shouldn't usually get unfolded instructions, but strange
things can happen with fuzzed options.
Does the code mishandle that case? It looke
Ah whoops- I didn't see this before sending off V4 just now, my apologies.
I'll try my best to get this implemented before the end of the day so that
it doesn't miss the deadline.
On 09/01/2025 23:04, Richard Sandiford wrote:
Akram Ahmad writes:
In the above example, subtracti
Hi Kyrill,
Thanks for the very quick response! V4 of the patch can be found
below the line.
Best wishes,
Akram
---
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturatin
Hi Kyrill,
Thanks for the feedback on V2. I found a pattern which works for
the open-coded signed arithmetic, and I've implemented the other
feedback you provided as well.
I've send the modified patch in this thread as the SVE patch [2/2]
hasn't been changed, but I'm happy to send the entire V3 p
Hi Richard,
Thanks for the feedback. I've copied in the resulting patch here- if
this is okay, please could it be committed on my behalf? The patch
continues below.
Many thanks,
Akram
---
GIMPLE code which performs a narrowing truncation on the result of a
vector concatenation currently result
Hi Kyrill,
On 17/12/2024 15:15, Kyrylo Tkachov wrote:
We avoid using the __builtin_aarch64_* builtins in test cases as they are
undocumented and we don’t make any guarantees about their stability to users.
I’d prefer if the saturating operation was open-coded in C. I expect the midend
machiner
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668794.html
On 14/11/2024 15:53, Akram Ahmad wrote:
Hi all,
This patch series introduces standard names for scalar, Adv. SIMD, and
SVE saturating arithmetic instructions in the aarch64 backend.
Additional tests are added for
Pinging
On 27/11/2024 20:27, Akram Ahmad wrote:
Hi all,
This patch series adds support for 2 new cases of unsigned scalar saturating
arithmetic
(one addition, one subtraction). This results in more valid patterns being
recognised,
which results in a call to .SAT_ADD or .SAT_SUB where
Ping
On 27/11/2024 20:27, Akram Ahmad wrote:
Hi all,
This patch series adds support for 2 new cases of unsigned scalar saturating
arithmetic
(one addition, one subtraction). This results in more valid patterns being
recognised,
which results in a call to .SAT_ADD or .SAT_SUB where relevant
ect modes for UZP1, and adding a test for each
mode affected by the new insns. Furthermore, support for floating-point is
added,
having accidentally been omitted from V1.
Best wishes,
Akram
---
Akram Ahmad (1):
aarch64: remove extra XTN in vector concatenation
gcc/config/aarch64/aarch64-simd
GIMPLE code which performs a narrowing truncation on the result of a
vector concatenation currently results in an unnecessary XTN being
emitted following a UZP1 to concate the operands. In cases such as this,
UZP1 should instead use a smaller arrangement specifier to replace the
XTN instruction. Th
Ping
Hi Kyrill, thanks for the very quick response!
On 02/12/2024 15:09, Kyrylo Tkachov wrote:
Thanks for the patch. As this is sent after the end of stage1 and is not
finishing support for an architecture feature perhaps we should stage this for
GCC 16.
But if it fixes a performance problem in a r
insn is appropriate.
Similarly, I would also appreciate any suggestions for other test cases
that should be covered for this optimisation.
Many thanks,
Akram
---
Akram Ahmad (1):
aarch64: remove extra XTN in vector concatenation
gcc/config/aarch64/aarch64-simd.md| 16
GIMPLE code which performs a narrowing truncation on the result of a
vector concatenation currently results in an unnecessary XTN being
emitted following a UZP1 to concate the operands. In cases such as this,
UZP1 should instead use a smaller arrangement specifier to replace the
XTN instruction. Th
Just pinging v2 of this patch series
On 14/11/2024 15:53, Akram Ahmad wrote:
Hi all,
This patch series introduces standard names for scalar, Adv. SIMD, and
SVE saturating arithmetic instructions in the aarch64 backend.
Additional tests are added for scalar saturating arithmetic, as well
as to
This patch adds a new case for unsigned scalar saturating subtraction
using a branch with a greater-than-or-equal condition. For example,
X >= (X - Y) ? (X - Y) : 0
is transformed into SAT_SUB (X, Y) when X and Y are unsigned scalars,
which therefore correctly matches more cases of IFN SAT_SUB. N
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative.
The pattern for case 7 currently does not accept the alternative
where Y is used in the condition. Ther
Support for middle-end representation of saturating arithmetic (via
IFN_SAT_ADD or IFN_SAT_SUB) cannot be determined externally, making it
currently impossible to selectively skip relevant tests on targets which
do not support this.
This patch adds new dg-require-effective-target keywords for each
do so.
Many thanks,
Akram
---
Akram Ahmad (3):
testsuite: Support dg-require-effective-target for us{add, sub}
Match: support new case of unsigned scalar SAT_SUB
Match: make SAT_ADD case 7 commutative
gcc/match.pd | 12 +++-
.../gcc.dg/tree-ssa/sat-u-add-ma
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturating arithmetic and their corresponding
builtins are changed to use these standard names too.
Using the standard names for
Rename the existing SVE unpredicated saturating arithmetic instructions
to use standard names which are used by IFN_SAT_ADD and IFN_SAT_SUB.
gcc/ChangeLog:
* config/aarch64/aarch64-sve.md: Rename insns
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/aarch64/sve/saturating_ar
is ok, could this be committed
for me please? I do not have commit rights.
Many thanks,
Akram
---
Akram Ahmad (2):
aarch64: Use standard names for saturating arithmetic
aarch64: Use standard names for SVE saturating arithmetic
gcc/config/aarch64/aarch64-builtins.cc| 13 +
gcc/con
On 31/10/2024 08:00, Richard Biener wrote:
On Wed, Oct 30, 2024 at 4:46 PM Akram Ahmad wrote:
On 29/10/2024 12:48, Richard Biener wrote:
The testcases will FAIL unless the target has support for .SAT_ADD - you want to
add proper effective target tests here.
The match.pd part looks OK to me
On 29/10/2024 12:48, Richard Biener wrote:
On Mon, Oct 28, 2024 at 4:45 PM Akram Ahmad wrote:
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative.
The pattern for case 7 currently does not accept the alternative
where Y is used in the condition. Ther
This patch adds a new case for unsigned scalar saturating subtraction
using a branch with a greater-than-or-equal condition. For example,
X >= (X - Y) ? (X - Y) : 0
is transformed into SAT_SUB (X, Y) when X and Y are unsigned scalars,
which therefore correctly matches more cases of IFN SAT_SUB. N
ement for
usadd_left_part_1.
Many thanks,
Akram
---
Akram Ahmad (2):
Match: support new case of unsigned scalar SAT_SUB
Match: make SAT_ADD case 7 commutative
gcc/match.pd | 12 +--
.../gcc.dg/tree-ssa/sat-u-add-match-1-u16.c
On 24/10/2024 16:06, Richard Biener wrote:
Can you check whether removing the :c from the (plus in
usadd_left_part_1 keeps things
working?
Hi Richard,
Thanks for the feedback. I've written some tests and can confirm that they
pass as expected with these two changes being made (removal of :c in
On 23/10/2024 12:20, Richard Sandiford wrote:
Thanks for doing this. The approach looks good. My main question is:
are we sure that we want to use the Advanced SIMD instructions for
signed saturating SI and DI arithmetic on GPRs? E.g. for addition,
we only saturate at the negative limit if bot
Case 7 of unsigned scalar saturating addition defines
SAT_ADD = X <= (X + Y) ? (X + Y) : -1. This is the same as
SAT_ADD = Y <= (X + Y) ? (X + Y) : -1 due to usadd_left_part_1
being commutative.
The pattern for case 7 currently does not accept the alternative
where Y is used in the condition. Ther
This patch adds a new case for unsigned scalar saturating subtraction
using a branch with a greater-than-or-equal condition. For example,
X >= (X - Y) ? (X - Y) : 0
is transformed into SAT_SUB (X, Y) when X and Y are unsigned scalars,
which therefore correctly matches more cases of IFN SA
pass with no failures.
Many thanks,
Akram
---
Akram Ahmad (2):
Match: support new case of unsigned scalar SAT_SUB
Match: make SAT_ADD case 7 commutative
gcc/match.pd | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--
2.34.1
in the backend. This affects the NEON intrinsics
for these two modes as well. This is the cause of a few test failures,
otherwise there are no regressions on aarch64-none-linux-gnu.
SVE currently uses the unpredicated version of the instruction in the
backend.
Many thanks,
Akram
---
Akram Ahmad
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturating arithmetic and their corresponding
builtins are changed to use these standard names too.
Using the standard names for
Rename the existing SVE unpredicated saturating arithmetic instructions
to use standard names which are used by IFN_SAT_ADD and IFN_SAT_SUB.
gcc/ChangeLog:
* config/aarch64/aarch64-sve.md: Rename insns
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/aarch64/sve/saturating_ar
36 matches
Mail list logo
