[Bug target/112445] [14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1861 unable to find a register to spill: {*umulditi3_1} with -O -march=cascadelake -fwrapv since r14-4968-g89e5d902fc55ad

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Just changing
> --- i386.md.xx	2023-11-22 09:47:22.746637132 +0100
> +++ i386.md	2023-11-22 20:38:07.216218697 +0100
> @@ -9984,7 +9984,7 @@
>    [(set (match_operand:<DWI> 0 "register_operand" "=r,A")
>  	(mult:<DWI>
>  	  (zero_extend:<DWI>
> -	    (match_operand:DWIH 1 "register_operand" "%d,a"))
> +	    (match_operand:DWIH 1 "register_operand" "%d,0"))
>  	  (zero_extend:<DWI>
>  	    (match_operand:DWIH 2 "nonimmediate_operand" "rm,rm"))))
>     (clobber (reg:CC FLAGS_REG))]
> makes the testcase pass.  A question is how RA treats 0 constraint when the
> two operands have different modes, if it is basically the same as a in that

LRA treats the same way as reload pass.  It is the same hard reg for LE target.
 For BE they are different if they require different number of hard regs.


> case, meaning that the first input operand will never be in %rdx even when
> the A constraint contains %rax and %rdx registers (but the double-word mode
> implies it must be low part in %rax high part in $rdx).

I looked at the testcase.  It seems it can be fixed by different placement of
splitting insns.  So I believe the bug will stay and can be latent if we fix
the PR by some other way.

I'll start to work on this bug on Monday as I will be absent the next two days.