https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
--- Comment #6 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #5) > So yeah it seems that there are three issues here: > > 1) We should probably have an r -> r alternative for *neon_mov. > 2) The costs are now flipped from what they were before, for some reason the > VFP regs are now way more expensive. > 3) reload shouldn't have ICEd since it says > > r113: preferred GENERAL_REGS, alternative ALL_REGS, allocno ALL_REGS > > so it hasn't excluded ALL_REGS as an alternative, which should have either > a) used the VPF register again or > b) spilled the register since we have a m -> r and r -> m pattern. p113 is used in 2 move insns, both containing 2 general hard regs (r0 and r2). So it is natural to use general regs for p113. At least arm_register_move_cost says this. LRA does not check constraints because arm_register_move_cost for general regs in any mode returns 2. Such LRA/reload behaviour for cost 2 is described in gcc documentation. So adding r,r alternative to neon_movv8qi or increasing move cost for GENERAL_REGS or both will solve the problem. Actually the cost should be increased in anyway. It can not be 2 because we need 2 general hard regs for V8QImode. And this is a work for arm target maintainers.
