Re: new port: msp430-elf, revision 2

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Tue, May 14, 2013 at 2:51 PM, nick clifton wrote:
> Hi Steven,
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> simplify_subreg_regno:
>
>   http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00135.html

Right, I've seen Jeff's comment and your reply.


> The LRA conversion is a work in progress however, and one that does not have
> my highest priority, so we would really like to have the current
> reload-heavy version accepted.  The current version works, and it will be
> converted to LRA in the future, so is it really necessary to block its
> adoption now ?

As long as the work to convert to LRA is completed ;-)

I understand the port is ready (maybe even already since very long)
and works, and even if I would want to block its adoption I'd be in no
position to do so. That wasn't the purpose of my message.

What worries me a lot, is that there are so many half-finished bits
and conversions in GCC, some ports/passes/... doing this and others
doing that, that it's very hard to bring some structure back into the
compiler and clean things up. Just see
http://gcc.gnu.org/wiki/Partial_Transitions (which is out-of-date but
not nearly complete), gcc.gnu.org/backends.html (the "does
not"-fields), the sched-deps representations and hooks, and so on. I
would like new contributions to try and be as "modern" as reasonably
possible. E.g. if someone at this point would contribute the SH port
(talk about reload-heavy...) I don't think that'd be good for the GCC
as a product overall. Likewise for ports that don't use define_c_enum
for unspec{,v}, define_peephole, and so on.

Ciao!
Steven