[Bug target/90024] [7/8/9 Regression] ICE on AArch32 NEON mov with TImode constant.

[matmal01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90024

Matthew Malcomson <matmal01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm
      Known to work|                            |4.9.0

--- Comment #1 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
The "*neon_mov<mode>" patterns for 128 bit sized quantities uses the "Dn"
constraint to match vmov.f32 and vmov.i<vec-width> patterns.

This constraint boils down to using the `neon_immediate_valid` function.
Once the constraint has matched, the output C statement asserts the same
function
passes.

The output C statement calls `neon_immediate_valid` with the mode taken from
the
iterator, while the constraint takes the mode from the operand.


In the above testcase the operand is a CONST_INT, which means the constraint
passes VOIDmode (treated the same as DImode in `neon_immediate_valid`), while
the C statement passes TImode (the mode of the iterator).

This causes second call to `neon_immediate_valid` to fail as the value provided
is only valid in DImode but not TImode, and that causes the ICE.


The attached patch splits the original "Dn" constraint into three new
constraints, "DN" for TImode CONST_INT, "Dn" for DImode CONST_INT, and "Dm" for
CONST_VECTOR.
This requires one extra alternative in the "*neon_mov<mode>" patterns, but
makes it clear from the constraint what mode is being used.

We use the "DN" constraint for the define_insn that matches TImode values, and
hence avoid the above problem.