Re: RFC: mips SB-1 DFA scheduler

[Jim Wilson <wilson at specifixinc dot com>]

On Fri, 2004-02-27 at 05:29, Richard Sandiford wrote:
> I definitely prefer your suggestion of splitting the existing types.

OK.  I will work on patches for this.

> Sounds like we should bite the bullet and do the split.  The rm7000 and
> rm9000 schedulers use a similar trick and I've some local vr5500 patches
> that need it too.

Ah, yes, that is why I did it this way, because I looking for ideas in
the other md files, and noticed the hilo_operand trick in the 9000.md
file.  I forgot about that.  I need a little bit more for the SB-1
though because the lo/hi regs accesses have different latencies in one
case, as they are written in different cycles.

Also, I forgot to mention it, but I added lo_operand/fp_register_operand
to PREDICATE_CODES out of habit, because they look like predicates, but
I am not convinced that is necessary.  I think this only matters for
predicates used by recog, and these helper functions aren't.  So I
believe this part of my patch is unnecessary.  This is moot if I get rid
of the helper functions in favor of a more fine grained type attribute
though.

> Do you mean mtc1 and mfc1?

Yes.  More sloppiness on my part.

> > Most of the rest of the patch I expect is non-controversial.  The
> > mips_{ld,st}_address_bypass_p were borrowed from the IA-64 port.

> Since two ports need this, wouldn't it be better to move the code out
> of the back ends?

Loads and stores can have target dependent representations so this can
be a little tricky.  Consider the different ways that different targets
represent GOT loads.  If we see an unspec, we can't tell if this is a
load address or not, but the back end does know.

The functions I added to mips.c are different than the ones in the IA-64
backend.  The IA-64 one for instance has special support to recognize
the IA-64 specific prologue_allocate_stack and epilogue_deallocate_stack
patterns.  The IA-64 one has some support for looking inside UNSPECs. 
The ones I added to mips.c are simplified versions of the ones in the
IA-64 file.  I figured the special cases were probably not important at
the beginning, and if I do see special cases I need to handle later, I
can add the code then.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com