This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Committed, MMIX: fix PR43889, missing earlyclobber exposed by r154688


On Tue, 27 Apr 2010, Bernd Schmidt wrote:
> On 04/27/2010 04:31 PM, Hans-Peter Nilsson wrote:
> > I really see nothing wrong here and have to wonder where you're
> > coming from, or what it is that I (and Bonzini, it seems) are
> > missing.  Are you somehow not seeing the "=" on the clobber
> > constraint?
>
> I think I see your point now.  If the pseudo is live past the insn,
> we'll choose a register for the pair of matching operands that doesn't
> conflict with the pseudo.  That does seem to actually work.
>
> Still, it's a baffling way to write the pattern, and I think it would be
> somewhat cleaner to simply represent this with a "=r" constraint on the
> scratch, with any necessary register moves handled in the pattern.

If you still refer to the (clobber (match_scratch:DI 3 "=1")
part for an insn that clobbers that input, this is the canonical
idiom for writing an (expanded; anon) pattern that clobbers an
input.  You'll find this in several ports that has this need.

JFTR, because (I think I now see what's been bothering you) I
guess you refer to these actual insns and why they're written
that way... uh, well, I'll give you that. :-)

No actual need to clobber the *inputs*, I could have used any
other general register.  I don't quite remember why I did it
that way.  Perhaps I just wanted to cut down on the number of
operands in the asm output pattern for simplicity.

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]