This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-regalloc] fix_truncdi_nomemory, fix_truncdi_memory.
Jan Hubicka <jh@suse.cz> writes:
> > Hi,
> >
> > On Tue, 20 Aug 2002, Jan Hubicka wrote:
> >
> > > > > So & is ignored for "1" but holds for "f".
> > > >
> > > > It would be much clearer if this got rewritten "=1,&f" then.
> > >
> > > Isn't the earlyclobber global for all alternatives, like "=" is?
> >
> > No.
> I see. THen we can probably fix the i386 and other ports using it and
> keep new regalloc threading it differently.
So, '=&1f' must be rewritten as '=1,&f' ?
It was a second part of my question.
The first:
> Problem:
> (define_insn "fix_truncdi_memory"
> [(set (match_operand:DI 0 "memory_operand" "=m")
> (fix:DI (match_operand 1 "register_operand" "f")))
> -----------------------------^^ No mode definition here (I know why)
> (use (match_operand:HI 2 "memory_operand" "m"))
> (use (match_operand:HI 3 "memory_operand" "m"))
> (clobber (match_scratch:DF 4 "=&1f"))]
> ---------------------------^^ ----^^^ '=&1' refers to operands[1]
> "TARGET_80387 && FLOAT_MODE_P (GET_MODE (operands[1]))
> && (!SSE_FLOAT_MODE_P (GET_MODE (operands[1])) || !TARGET_64BIT)"
> "* operands[5] = operands[4]; return output_fix_trunc (insn, operands);"
> [(set_attr "type" "fistp")])
>
> operands[4] have a mode definition (DFmode), but operands[4] can be
> equal to operands[1] which can have different mode - IMHO it's wrong.
IMHO: at least it's strange. I can't understand how to interpret this in
new allocator.
Denis.