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.
