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)


On Mon, May 04, 2009 at 06:59:19PM -0400, DJ Delorie wrote:
> 
> It's been over a month, with no feedback (except Paolo, thanks :)
> 
> http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01725.html
> 
> As the trunk has been changing, I've had to make some minor changes,
> and took the opportunity to do some cleanup too.  The latest patch and
> new files are here: http://people.redhat.com/dj/mep/ (I tried to send
> it out last Thursday, but the email vanished, so I'm linking this
> time).
> 
> MeP support is current in all the other trees (binutils, sid, gdb,
> newlib).
> 
> I note there are three ports pending now.  Can we get some feedback
> from the SC (or whoever approves these) as to some approximate
> timeline as to when these will be looked at?

I looked at the configure patches, and they are ok.

My only concern is about validate_replace_rtx_subexp, and whether there is a
newer way of doing what it used to do.

Now, I just started looking at the MEP files, and looked at t-mep first.

In t-mep, you redefine GCC_FOR_TARGET to add -mlibrary.  I think a better
approach is to override TCFLAGS or T_CFLAGS, since these are setup for that
purpose.

Some things that you may want to consider in the port specific stuff (you don't
have to, but it might be useful to think about):

You create a md file by concantenating two mep.md intrinsics.md.  Now that the
md syntax has the (include "file.md") option, I suspect it is better to use
that, and then set MD_INCLUDES = $(srcdir)/config/mep/intrinsics.md.

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.

Its up to you whether you want to combine the expander and insn for things like
addsi3 and addsi3_internal.  Unless you have different variants of the machine,
I would combine the two.  If you do keep them separate, you might want to put a
* in front the of the internal name, so no gen_<foo>_internal function is
generated.

You might or might not want to move the *_operand functions to a
predicates.md.

You might want to move mep_reg_class_from_constriant, mep_extra_constraint and
mep_const_ok_for_letter_p into a constraints.md file.  I realize these were
probably written before the md file had the ability to define these.

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 don't know if you want farcall_list to be in garbage collected memory with
GTY(()) markers instead of using xmalloc.  It also may be useful to use a
hashtab for this instead of a linear list.

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


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