> * 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]
