[PATCH v2 0/1] arm: mve: fix out-of range literal pool for a const_vector [PR121810]

[Richard Earnshaw via Sourceware Forge]

Hi gcc-patches mailing list,
Richard Earnshaw <rearnsha@gcc.gnu.org> has requested that the following forgejo pull request
be published on the mailing list.

Created on: 2025-09-05 14:55:01+00:00
Latest update: 2025-09-09 13:41:59+00:00
Changes: 1 changed files, 6 additions, 6 deletions
Head revision: rearnsha/gcc-TEST ref mve_pool_range commit e6e4b78817945a10b319062ae98ba903fadbcd50
Base revision: gcc/gcc-TEST ref trunk commit 052c1d8284b1eb16474473b341fd83f99e8664c8 r16-3601-g052c1d8284b1eb
Merge base: 052c1d8284b1eb16474473b341fd83f99e8664c8
Full diff url: https://forge.sourceware.org/gcc/gcc-TEST/pulls/73.diff
Discussion:  https://forge.sourceware.org/gcc/gcc-TEST/pulls/73
Requested Reviewers: clyon

For the pattern mve_mov<mode>, the alternative that describes literal
pool support is incorrect.  This leads to compiler getting the
calculations wrong for the available distance to the next pool
fragment because the selected alternative is a shorter sequence than
the correct one.  In particular the sequence generated for a 128-bit
constant is

	vldr	 d0, Pool    // Insn length 4
	vldr	 d1, Pool+8  // Insn length 4

Note that the second instruction needs 4 bytes more range than the
first because the PC has advanced by 4 bytes, but the next slot in the
pool has advanced by 8.

The fix is to move the 'Ui' constraint to the correct alternative
and to move the pool-range attributes to that alternative as well.

I've fixed a couple of other nits in this code at the same time:
- the thumb2_neg_pool_range attribute was misnamed (as neg_pool_range),
meaning it was ignored in Thumb state, which is the only time this
pattern is available.
- the load range was not a multiple of 4, which makes no sense for
an insn sequence that is a multiple of 4 bytes long.  I've rounded the
value down out of caution, but it may well have been OK with 1020 as
the forward range.

I'm not adding a testcase for this patch; the code to reproduce is
simply too complex to reliably test for a regression.

gcc/ChangeLog:
	PR target/121810
	* config/arm/mve.md (mve_mov<mode>): Move the Ui constraint
	and pool_range attributes to the final alternative.  Fix
	the forward range value and correctly name the negative
	range.

Thanks for taking the time to contribute to GCC!

Please be advised that https://forge.sourceware.org/ is currently a trial
that is being used by the GCC community to experiment with a new workflow
based on pull requests.

Pull requests sent here may be forgotten or ignored. Patches that you want to
propose for inclusion in GCC should use the existing email-based workflow,
see https://gcc.gnu.org/contribute.html


Changed files:
- M: gcc/config/arm/mve.md


Richard Earnshaw (1):
  arm: mve: fix out-of range literal pool for a const_vector [PR121810]

 gcc/config/arm/mve.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Range-diff against v1:
1:  d09fc6857797 ! 1:  e6e4b7881794 arm: mve: fix out-of range literal pool for a const_vector [PR121810]
    @@ Commit message
         the correct one.  In particular the sequence generated for a 128-bit
         constant is
     
    -            vldr     d0, Pool    // Insn length 4
    -            vldr     d1, Pool+8  // Insn length 4
    +            vldr     d0, Pool    // Insn length 4, alternative 7 (part 1)
    +            vldr     d1, Pool+8  // Insn length 4, alternative 7 (part 2)
     
         Note that the second instruction needs 4 bytes more range than the
         first because the PC has advanced by 4 bytes, but the next slot in the
-- 
2.50.1