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.
