668df9e769
The load_pair_lanes<mode> patterns match a vec_concat of two
adjacent 64-bit memory locations as a single 128-bit load.
The Utq constraint made sure that the address was suitable
for a 128-bit vector, but this meant that it allowed some
addresses that aren't valid for the 64-bit element mode.
Two obvious fixes were:
(1) Continue to accept addresses that aren't valid for the element
modes. This would mean changing the mode of operands[1] before
printing it. It would also mean using a custom predicate instead
of the current memory_operand.
(2) Restrict addresses to the intersection of those that are valid
element and vector addresses.
The problem with (1) is that, as well as being more complicated,
it doesn't deal with the fact that we still have a memory_operand
for the second element. If we encourage the first operand to be
outside the range of a normal element memory_operand, we'll have
to reload the second operand to make it valid. This reload will
often be dead code, but will be kept around because the RTL
pattern makes it look as though the second element address
is still needed.
This patch therefore does (2) instead.
As mentioned in the PR notes, I think we have a general problem
with the way that the aarch64 port deals with paired addresses.
There's nothing to guarantee that the two addresses will be
reloaded in a way that keeps them “obviously” adjacent, so the
rtx_equal_p conditions could fail if something rechecked them
later.
For this particular pattern, I think it would be better to teach
simplify-rtx.c to fold the vec_concat to a normal vector memory
reference, to remove any suggestion that targets should try to
match the unsimplified form. That obviously wouldn't be suitable
for backports though.
gcc/
PR target/100305
* config/aarch64/constraints.md (Utq): Require the address to
be valid for both the element mode and for V2DImode.
gcc/testsuite/
PR target/100305
* gcc.c-torture/compile/pr100305.c: New test.
This directory contains the GNU Compiler Collection (GCC). The GNU Compiler Collection is free software. See the files whose names start with COPYING for copying permission. The manuals, and some of the runtime libraries, are under different terms; see the individual source files for details. The directory INSTALL contains copies of the installation information as HTML and plain text. The source of this information is gcc/doc/install.texi. The installation information includes details of what is included in the GCC sources and what files GCC installs. See the file gcc/doc/gcc.texi (together with other files that it includes) for usage and porting information. An online readable version of the manual is in the files gcc/doc/gcc.info*. See http://gcc.gnu.org/bugs/ for how to report bugs usefully. Copyright years on GCC source files may be listed using range notation, e.g., 1987-2012, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually.