On Mon, Mar 04, 2024 at 09:34:30AM +0100, Uros Bizjak wrote:
> > --- gcc/config/i386/i386-expand.cc.jj 2024-03-01 14:56:34.120925989 +0100
> > +++ gcc/config/i386/i386-expand.cc 2024-03-03 18:41:08.278793046 +0100
> > @@ -451,6 +451,20 @@ ix86_expand_move (machine_mode mode, rtx
> > && GET_MODE (SUBREG_REG (op1)) == DImode
> > && SUBREG_BYTE (op1) == 0)
> > op1 = gen_rtx_ZERO_EXTEND (TImode, SUBREG_REG (op1));
> > + /* As not all values in XFmode are representable in real_value,
> > + we might be called with unfoldable SUBREGs of constants. */
> > + if (mode == XFmode
> > + && CONSTANT_P (SUBREG_REG (op1))
> > + && can_create_pseudo_p ())
>
> We have quite some unguarded force_regs in ix86_expand_move. While it
> doesn't hurt to have an extra safety net, is there a particular reason
> for can_create_pseudo_p check in the added code?
Various other places in ix86_expand_move do check can_create_pseudo_p, the
case I've mostly copied this from in ix86_expand_vector_move also does that,
and then there is the
Therefore, when given such a pair of operands, the pattern must
generate RTL which needs no reloading and needs no temporary
registers--no registers other than the operands. For example, if
you support the pattern with a 'define_expand', then in such a case
the 'define_expand' mustn't call 'force_reg' or any other such
function which might generate new pseudo registers.
in mov<M> description, which initially scared me off from using it at all.
Guess we'll ICE either way if something like that appears during RA.
Jakub
