[Bug target/61154] [ARM] wide-int merge introduced regressions in vshuf tests

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154

--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
This code is doing an OImode ASHIFT and fails the check:

#if TARGET_SUPPORTS_WIDE_INT == 0
      /* This assert keeps the simplification from producing a result
     that cannot be represented in a CONST_DOUBLE but a lot of
     upstream callers expect that this function never fails to
     simplify something and so you if you added this to the test
     above the code would die later anyway.  If this assert
     happens, you just need to make the port support wide int.  */
      gcc_assert (width <= HOST_BITS_PER_DOUBLE_INT);
#endif

since without CONST_WIDE_INT we won't be able to represent all
results correctly.

Unfortunately porting to CONST_WIDE_INT is something that needs
knowledge of the target-specific code, but it shouldn't be much work.
It's just a case of auditing each use of const_double in config/arm
to see whether it is handling integer const_doubles or floating-point
const_doubles.  Since ARM is a 32-bit target and since HWI and CONST_INT
are 64 bits, I assume most places really are handling floating-point values.
(A grep makes that obvious for some things, but arm_immediate_di_operand
does accept const_double.  I'm not sure whether that's just a left-over
from pre need_64bit_hwint days though.)

Adding:

#define TARGET_SUPPORTS_WIDE_INT 1

does fix the ICE but it'd be good audit the use of const_doubles too.