Re: GCC 4.0 Status Report (2005-02-03)

[Mostafa Hagog <MUSTAFA at il dot ibm dot com>]

Please discard the previous message it was send by mistake.

gcc-owner@gcc.gnu.org wrote on 12/02/2005 20:34:57:

>
>
>
>
> > * Project Title
> I. SMS (Modulo Scheduling) Improvements.
>
> >
> > * Project Contributors
> Mostafa Hagog
>
> >
> > * Dependencies
> No dependencies.
>
> >
> > * Delivery Date
>
> Ready, currenly committed to the autovect-branch.
>
> >
> > * Description
> >
> >   Describe the project *in detail*.
> >
> >   What will you be doing?
>
> 1. Make the tree loop-versioning usable in RTL cfg-layout mode by making
it
>    a cfg hook.
> 2. Move SMS to use cfg-layout mode.
> 3. Use loop information to detect simple loops.
> 4. Replace the loop versioning in SMS by using the RTL loop-versioning.
> 5. Several other improvements:
>    1. Check if the SMSed loop kernel is more efficient in means of
>  number of
>       cycles if not undo the changes. We do this by feeding the loop
kernel
> into
>       the DFA and counting the number of cycles before and after
>    SMS - if we didn't improve (there is a chance because of the register
>    copies we add) we prefer the original loop.
>
>   a. Ignore register anti-depences - use register copies instead.
>   b. Add backtracking to the scheduling algorithm;
>      When failing to find a cyclen within a kernel of II cycles for a
>      given node we used to restart the whole process with kernel of II +
1.
>      Now we try to un-schedule some of the nodes that the one we failed
on
>      depends on and schedule the failing node first, then try the other
> nodes.
>
> >
> >   What parts of the compiler will be modified?
>
> modulo-sched.c, ddg.c
>
> >
> >   What will the benefits of your change be?  (Be specific -- for
> >   example, if you will be improving code quality, indicate what kind
> >   of code, and, if possible, how great the improvement will be.)
> 1. More loops will be applicable to SMS.
> 2. SMS is undone when it is not profitable, so we don't increase code
>    size in cases we don't gain much.
> 3. Better schedules - due to backtracking.
>
> >
> >   What risks do you foresee?  (If you say "none", you'll be asked to
> >   resubmit...)  What will you be doing to mitigate those risks?
>
> The only risk is to affect the tree level loop versioning and
> the modulo-scheduling.
>
> >
> > I'll synthesize this information and make decisions about schedules
> > for 4.1 once I have the proposals in hand.
> >
> > To that end, please submit your proposal(s) by February 17th.  Late
> > proposals will still be considered.  In fact, there's nothing to
> > prevent us from including work conceived developed later in the cycle,
> > if that's appropriate.  So, the February 17th date is not a drop-dead
> > deadlin for 4.1 material in any way.
> >
> > But, I would like to get a sense of what projects are already out
> > there, so that we can start bringing them into GCC 4.1.  By staging
> > the integration, we can take some time to stabilize after each major
> > contribution.
> >
> > I will create the GCC 4.0 branch on February 24th, after posting
> > information about initial GCC 4.1 development, based on the proposals
> > I have received by the 17th.  Based on current progress, my
> > expectation is that the branch will be in very good shape by then.
> >
> > Therefore, my current expectation for a GCC 4.0 release date is April
> 15th.
> >
> > --
> > Mark Mitchell
> > CodeSourcery, LLC
> > mark@codesourcery.com
>