This is the mail archive of the
mailing list for the GCC project.
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:
I've updated the port to make all the recommended changes except
> 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
> 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.