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
