Re: core changes for mep port

[Jeffrey Law <law at redhat dot com>]

On Tue, 2007-03-27 at 07:47 +0200, Steven Bosscher wrote:
> On 3/27/07, DJ Delorie <dj@redhat.com> wrote:
> >        * postreload.c (reload_cse_move2add): Don't look for strict lowparts
> >        of coprocessor modes.
> 
> This changes is not in your patch.
> 
> 
> >        * c-typeck.c (convert_for_assignment): Don't relax reference check.
> 
> And neither is this one.
> 
> You have machine modes for a co-processor.  Somehow that doesn't feel
> right to me. What if there comes a new architecture with two different
> kind of co-processors? Will we have COPRO2_MODE_P/copro2_modes/etc.?
There's certainly processors with multiple co-processors; the original
MEP designs certainly had multiple co-processors in mind as well.

You can model this by simply globbing all the co-processor modes
together.  It's far from ideal though.
> 
> Also:
> 
> >       * 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 :-)

Note my comments say absolutely nothing about this particular 
implementation...  I haven't looked at the changes at all.


> So shouldn't this change be guarded by some kind of kost or
> profitability checks, etc.?
It's probably always going to be profitable on the architectures that
have these kind of capabilities.  Moving values between the main unit
and co-processors it typically slow, very slow, often they have to go
through memory or at least flush the pipeline.


Jeff