This is the mail archive of the
mailing list for the GCC project.
Re: Remove sel-sched?
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Andrey Belevantsev <abel at ispras dot ru>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 15 Jan 2016 14:56:10 +0100
- Subject: Re: Remove sel-sched?
- Authentication-results: sourceware.org; auth=none
- References: <569696A5 dot 9000204 at redhat dot com> <56974947 dot 3060004 at ispras dot ru> <5697DA29 dot 3090404 at redhat dot com> <5698C06F dot 2000803 at ispras dot ru> <CAFiYyc1=3MwKGU5K_6uXwfK9Nvos89cfYgpwp57-2Tm2=ah5Dw at mail dot gmail dot com>
On 01/15/2016 11:13 AM, Richard Biener wrote:
Btw, I'd like people to start thinking if the scheduling algorithms
working on loops
(and sometimes requiring unrolling of loops) can be implemented in a way to
apply that unrolling on the GIMPLE level (not the scheduling itself of course).
Thus have an analysis phase (for the unrolling compute) that can be shared
Scheduling of loads / stores might still happen on GIMPLE if we have a good
enough idea of register pressure - I remember we jumped throuhg hoops in the
past to get better dependence info on RTL for this (ddr export to RTL, never
Basically unrolling on RTL should go away.
I don't think that's such a great idea. For C6X modulo scheduling I
actually wanted unrolling during the final sched phase. I don't expect
to be working on anything like this in the foreseeable future, but IMO
at the gimple stage we simply don't know enough to make reasonable
decisions for certain targets.