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: [ping 3] New port: Toshiba Media Processor (mep-elf)


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.

> 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.

> 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.


Thanks,
DJ


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