Please discard the previous message it was send by mistake.
[EMAIL PROTECTED] 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
> > [EMAIL PROTECTED]
>
