On Mon, Mar 4, 2024 at 9:41 AM Jakub Jelinek <ja...@redhat.com> wrote: > > 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.
Thanks for the insight - it was PIC handling in ix86_expand_move that catched my eye, especially the TARGET_MACHO part that looks like it was somehow left behind. OTOH, the whole ix86_expand_move would need some TLC anyway. FAOD - the patch is OK as is. Thanks, Uros.
