Re: core changes for mep port

[Ian Lance Taylor <iant at google dot com>]

Jeffrey Law <law@redhat.com> writes:

> > >       * expmed.c (expand_mult): If the variable operand is a coprocessor
> > >       value, use a coprocessor accumulator.
> > 
> > Why?  Isn't this an architecture specific decision to make?  Iff this
> > will ever be useful to other architectures than MEP (which I seriously
> > doubt), it could be better for that arch to use a normal mode.
> Oh, it could definitely be useful on other architectures; I've done GCC
> work on architectures were it would certainly have been advantageous to
> have this capability.  You could even model the MIPS in this manner and
> probably get better code for integer multiply-accumulate operations :-)

Can you expand on that?  As far as I can see, this patch only works
for code which is written specifically to take advantage of it.  If
you don't declare your variables using __attribute__ ((mode (COPxx))),
then you don't get the coprocessor modes.  So it seems that at best
this facility would permit somebody to write their code for a specific
MIPS implementation and get better code.  For anybody who was willing
to do that, for MIPS we could provide a similar facility using a
builtin function.  And actually for MIPS we could provide a similar
facility with a machine dependent register classing pass--I did that
in the past for this sort of thing.  It has the advantage of only
requiring a new target hook and a new set_reg_class function, and is
thus easy to maintain.


I find that I'm still unclear on what this facility is used for.  I
think I understand that the chip has a main processor and a
coprocessor.  It is expensive to move data between the two.  Both of
them have basic arithmetic instructions (and no doubt other stuff as
well).  Both can run simultaneously.  Since we want to run them
simultaneously for speed, we want to make sure that values which are
going to be used by coprocessor instructions are kept in coprocessor
registers as much as possible.

So far, so good.  But: if I understand the patch, in order to use the
coprocessor, the user must write their code using special types.  Is
that an important and desirable feature?  Or is that taking the fact
that the compiler doesn't know how to handle register allocation and
scheduling for this processor and pushing the problem onto the user?
To put it another way, what happens with code that is not specially
written for this processor?

Ian