[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #4)
> Perhaps:
> (define_insn_and_split "*concat<mode><dwi>3_1"
>   [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=ro,r,r")
>         (any_or_plus:<DWI>
>           (ashift:<DWI> (match_operand:<DWI> 1 "nonimmediate_operand"
> "r,o,r")
>                         (match_operand:<DWI> 2 "const_int_operand"))
>           (zero_extend:<DWI> (match_operand:DWIH 3 "nonimmediate_operand"
> "r,r,o"))))]
> 
> I hope this helps.

You're probably right, but:
1) I don't see why operands[1] or operands[3] can't be both memory operands
2) I don't see why they should use o constraint, while for operands[0] we need
   it to be offsettable, because we need to refer to both of its halves, but
   for the others we just refer to those memories or their low parts (which on
   little endian comes first).  Though, maybe it isn't a good idea to narrow
   128-bit or 64-bit loads to just 64-bit or 32-bit loads of their low half,
   the former might trap while the latter might succeed; so maybe limit
   nonimmediate_operand on inputs to zero_extend operands?
On the other side, split_double_concat needs to take into account when the
destination
and/or source are MEMs and some registers are used in their addresses.