https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #11) > (In reply to Jakub Jelinek from comment #10) > > Guess the first question is if we want to change this for GCC 15 or if that > > is too late for that. > > I think this is just tricky enough to leave it for GCC 16. Ok. > > As you wrote, the DImode with SImode result pattern could be also using > > if_then_else, and then for the zext one we could just have a combine pattern > > which has the expected constant in the input instead of a register and split > > that later into UNSPEC or something like that. > > Due to the "may" part, I'd just skip zero_extend cases. The point is that GCC chooses which constant it stores into the register. And as we will store there just 64 and nothing else at least in the near future, the zero extend case will work on all CPUs (some will preserve the whole register including the zeros, others will clear the upper 32 bits of it). The pattern could as well just hardcode the constant and force it into a separate mov only very late just to verify no other constant got matched. Though, UNSPEC would do the same job, one really can't change what is fed into an UNSPEC operand, because generic code doesn't know what the operation does.
