This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Committed, MMIX: fix PR43889, missing earlyclobber exposed by r154688
On Tue, 27 Apr 2010, Bernd Schmidt wrote:
> On 04/27/2010 02:40 PM, Hans-Peter Nilsson wrote:
> > On Tue, 27 Apr 2010, Bernd Schmidt wrote:
> >
> >> On 04/27/2010 02:59 AM, Hans-Peter Nilsson wrote:
> >>> Index: gcc/config/mmix/mmix.md
> >>> ===================================================================
> >>> --- gcc/config/mmix/mmix.md (revision 158753)
> >>> +++ gcc/config/mmix/mmix.md (working copy)
> >>> @@ -333,7 +333,7 @@
> >>> ;; The %2-is-%1-case is there just to make sure things don't fail. Could
> >>> ;; presumably happen with optimizations off; no evidence.
> >>> (define_insn "*divdi3_nonknuth"
> >>> - [(set (match_operand:DI 0 "register_operand" "=&r,r")
> >>> + [(set (match_operand:DI 0 "register_operand" "=&r,&r")
> >>> (div:DI (match_operand:DI 1 "register_operand" "r,r")
> >>> (match_operand:DI 2 "register_operand" "1,r")))
> >>> (clobber (match_scratch:DI 3 "=1,1"))
> >>> @@ -359,7 +359,7 @@
> >>> ;; The %2-is-%1-case is there just to make sure things don't fail. Could
> >>> ;; presumably happen with optimizations off; no evidence.
> >>> (define_insn "*moddi3_nonknuth"
> >>> - [(set (match_operand:DI 0 "register_operand" "=&r,r")
> >>> + [(set (match_operand:DI 0 "register_operand" "=&r,&r")
> >>> (mod:DI (match_operand:DI 1 "register_operand" "r,r")
> >>> (match_operand:DI 2 "register_operand" "1,r")))
> >>> (clobber (match_scratch:DI 3 "=1,1"))
> >>
> >> Even after your patch, I'm not at all convinced these are valid
> >> patterns, what with the "=1" matching constraint on a clobber.
> >
> > How is that? I don't see how I need an earlyclobber there too.
>
> Before reload, nothing tells the compiler that the inputs will be
> clobbered,
The "="s do, where need be. Before reload (really: before
register allocation) no temporaries are needed. For inputs that
don't die in the insn, register allocation will handle the
temporaries housekeeping.
> and the divdi3 expander shouldn't produce a pattern that
> clobbers the inputs.
What's wrong with that? I don't copy the inputs to temporaries
in the movdi3/divdi3 expanders, but that's just slightly
unhelpful to the register allocator, not wrong. Is that what
you mean?
> I don't see how a matching constraint on a
> match_scratch is ever going to do something sensible - you need to
> describe at all times that the input register is overwritten.
That's covered by the "=" and matching constraint.
If there was anything wrong with a match_scratch with a matching
constraint, we'd need a new mechanism to describe that; several
targets would be in peril.
brgds, H-P