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
