]> git.ipfire.org Git - thirdparty/gcc.git/commit
[PATCH v2] varasm: Use native_encode_rtx for constant vectors.
authorRobin Dapp <rdapp.gcc@gmail.com>
Tue, 31 Dec 2024 06:47:53 +0000 (23:47 -0700)
committerJeff Law <jlaw@ventanamicro.com>
Tue, 31 Dec 2024 06:47:53 +0000 (23:47 -0700)
commit509df13fbf0b3544cd39a9e0a5de11ce841bb185
treec1ccd5fce31d58176bd61c4b53e08a1415ccdb75
parentd369ddca549b5ff7d868b8f5ee139835b1f9382a
[PATCH v2] varasm: Use native_encode_rtx for constant vectors.

optimize_constant_pool hashes vector masks by native_encode_rtx and
merges identically hashed values in the constant pool.  Afterwards the
optimized values are written in output_constant_pool_2.

However, native_encode_rtx and output_constant_pool_2 disagree in their
encoding of vector masks:  native_encode_rtx does not pad with zeroes
while output_constant_pool_2 implicitly does.

In RVV's shuffle-evenodd-run.c there are two masks
  (a) "0101" for V4BI
  (b) "01010101" for V8BI and
that have the same representation/encoding ("1010101") in native_encode_rtx.
output_constant_pool_2 uses "101" for (a) and "1010101" for (b).

Now, optimize_constant_pool might happen to merge both masks using
(a) as representative.  Then, output_constant_pool_2 will output "1010"
which is only valid for the second mask as the implicit zero padding
doesn't agree with (b).
(b)'s "1010101" works for both masks as a V4BI load will ignore the last four
padding bits.

This patch makes output_constant_pool_2 use native_encode_rtx so both
functions will agree on an encoding and output the correct constant.

PR target/118036
gcc/ChangeLog:

* varasm.cc (output_constant_pool_2): Use native_encode_rtx for
building the memory image of a const vector mask.
gcc/varasm.cc