Status of m32c target?

[Sandra Loosemore]

On 01/15/2018 05:46 AM, Joseph Myers wrote:
> On Mon, 15 Jan 2018, Sebastian Huber wrote:
> 
>> On 13/01/18 00:16, Jeff Law wrote:
>>> On 01/12/2018 04:07 PM, Joseph Myers wrote:
>>>> On Fri, 12 Jan 2018, Jeff Law wrote:
>>>>
>>>>> I was going to suggest deprecation for gcc-8 given how badly it was
>>>>> broken in gcc-7 and the lack of maintenance on the target.
>>>> While we're considering deprecations, what happened to the idea of setting
>>>> a timescale by which cc0 targets need to be converted away from cc0 or be
>>>> removed?
>>> I don't think we ever really hashed through what that might look like.
>>>
>>> I'd be comfortable saying gcc-8 is the deprecation point.  I know some
>>> folks won't like that (someone already said so WRT the m68k, but didn't
>>> step up to do the conversion), but I think that unless we set a point
>>> nothing is likely to happen.
>>
>> How much work is it to convert the m68k to LRA. Is this person days, weeks,
>> months or years?
> 
> My understanding is that moving away from cc0 is much more work than
> moving to LRA once you've moved away from cc0 (both moves are desirable to
> modernize a port, the move away from cc0 needs to be done first).  But I
> don't have any more specific estimates.
> 
> https://gcc.gnu.org/wiki/CC0Transition
> https://gcc.gnu.org/wiki/LRAIsDefault

Based on my experience with Nios II last summer, enabling LRA is easy, 
but it exposes missing patterns/constraints in the machine description 
that the old reload let you get away with.  The nastiest type of these 
problems is where LRA thinks it has to do a bogus memory spill, which 
doesn't get fully optimized away again afterwards; tests still pass, but 
there's a code size regression.  :-(  So I think "how much work" is hard 
to quantify or predict in general.

-Sandra