[ping 3] New port: Toshiba Media Processor (mep-elf)

[Michael Meissner]

On Wed, May 13, 2009 at 10:26:14PM -0400, DJ Delorie wrote:
> 
> Michael and Joseph, thank you for taking the time to review the MeP
> port.  An updated port is available in the same place as before:
> 
> 	http://people.redhat.com/dj/mep/
> 
> I've updated the port to make all the recommended changes except
> these:
> 
> > My only concern is about validate_replace_rtx_subexp, and whether
> > there is a newer way of doing what it used to do.
> 
> If anyone can come up with an alternative to this, I'm willing to
> update the port.  I need to do a replace/validate but only on *part*
> of the insn (i.e. just set_dest or just set_src).
> 
> > I don't know if Toshiba plans other MEP processors, but it may or
> > may not be useful to move the scheduling stuff to a separate md
> > file.  Similarly most posts are now using constraints.md and
> > predicates.md for the constraints and predicates.
> 
> I'd like to defer this until such time in the future as there are two
> different pipelines to describe.

No problem.  I was just giving suggestions on how other ports are organized
these days.

> > In mep_rewrite_* you are rewritting insn trees on the fly.  I'm
> > wondering out load whether it would be better to define the insns in
> > the md file and/or use the expander and splits.  I must admit I
> > haven't gone into great detail of what you are doing, but it is
> > unusual for a backend file to rewrite insns on the fly like this.
> 
> I'd like to defer this too.  The MeP port does a lot of insn tweaking
> in the final stages; this one is part of peephole2.  The MeP port has
> a long optimization history internally and I'd like to avoid making
> changes "just because" unless/until the existing code causes
> build/compile problems.

It is your call, but sometimes these things come back to bite you, and if you
are the only port doing it, then nobody will notice when they add some other
pass or change how garbage collection works.

> > As previously discussed I think the source for the CGEN CPU
> > description needs to be included, even if maintained elsewhere, when
> > files generated from it are included.
> 
> The files are in src/cgen/cpu/mep* at the moment.  I can certainly
> check them in somewhere in the gcc tree, but I think Ben has a good
> point about considering a toplevel cpu/ directory which could more
> easily be kept in sync with src.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com