RE: SMS in gcc4.0

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

Hi Mark,

First of all I would like this discussion to be on the GCC mailing list; so
I am CCing the GCC mailing list (I hope this is OK with all the others).

"Davis, Mark" <mark.davis@intel.com> wrote on 31/03/2005 00:23:02:
> Mostafa & Gerald,
>
...
> It was mentioned that you folks had recently
> added SMS to gcc4.0, and I found the SMS paper from last year's gcc
> summit, and the description of SMS capabilities in gcc on the 4.0
> Features web site.  So the obvious approach is to use SMS for Itanium as
> well as Power5 and ....
>
> 1) Is SMS in gcc currently turned on for anything other than Power5?  I
> built a gcc4.0 for Itanium, and tried compiling the summation example
> from your paper (and some unrolled summation examples) using
>    -O3 -fmodulo-sched

We haven't yet put efforts to tune SMS for any specific architecture
(including Power5); SMS is implemented as general as the paper (mentioned
in http://gcc.gnu.org/news/sms.html) describes.

>
> but didn't see any difference in the .s file from not using
> -fmodulo-sched.  Are there other switches to turn on or dumps to look
> at?

I would suggest to start looking at SMS dumps to see what is doing there;
you can do so by adding the -dm flag to your compilation.  If you want you
can send me those dumps and I will look into them.

>
>
> I'm afraid I also was the origin of some of the "not very useful"
> comments about SMS.  From my way of thinking, if SMS doesn't have alias
> information or array dependence analysis, then SMS can't pipeline loops
> storing into array elements; therefore it is not very useful as a
> pipeliner, even if the swing modulo scheduling part is excellent.
> 2) Did I miss something here?

This is true; that's why we need accurate alias info in RTL level and this
is one of the efforts that one should concentrate on in improving SMS.

>
> I do not know about gcc internals (which is why I'm "project-managing",
> not "implementing"), so it was interesting and disturbing to hear what
> you and Vlad had to say about the different internal representations
> relative to when the SMS phase runs:
>    a) it seems to be too early to see the machine code
>    b) it's too late to have alias info
>
> 3) Do you agree with this assessment?

Its not black or white.  We need accurate alias info at the RTL level to be
able to software pipeline (SMS) the majority of the loops in the real world
programs- currently the RTL alias info is not accurate enough for those
loops.  Having the alias info make us capable of eliminating memory to
memory dependancies and thus make us know that we can interleave different
iterations of the loop.  The alias info is usually based on high level
representation of the code, the lower you are the more information you
lose.  One of the things that we would do is maintain this information
while we go down in the trees and RTL representation each pass that does
some transformation on the code will require additional effort to maintain
alias information which complicates it - that's why we want SMS to be  as
early as possible.  The other side of the coin is the modeling of the
machine resources (SMS is trying to solve a scheduling problem).  In SMS we
use DFA for resource modeling in which we follow each one of the
instruction resource usage and try to get the optimal schedule by moving
instructions among the different iteration trying to avoid resource
conflicts.  The problem in doing this early is that later passes can change
the resource usage of instructions when doing transformations on the code
(splitting instructions for example) and thus make the schedule not
optimal.  A good example for a way to handle this is the disabling of the
second scheduling pass for SMSed loops to prevent it from screwing the
schedules generated by SMS.  We can do the same for other passes and have a
cost model to decide if it is beneficial or not to perform the optimization
inside the SMSed loops.  Other problem that results from doing SMS before
register allocation is increasing the register pressure when SMS is
aggressive. IMO, this problem should be addressed later by using register
pressure estimation inside SMS.

> 4) Do you have any suggestions about using SMS for an in-order
> microarchitecture like Itanium which is more sensitive to the exact
> schedule than OOO microarchitectures like Power5?

Actually I would say that an in-order machine would benefit more from SMS
than an OOO machine, because theoretically OOO machines do the job of SMS
in hardware in many cases. The problem is not for IA64 being in-order, but
the fact that IA64 and other in-order machines are highly dependent on the
scheduling and among them SMS.  My suggestion is that we must invest in
lowering alias info to RTL and feed this information to the DDG used by SMS
which is implemented in ddg.c.

> 5) In the Intel compiler for Itanium, we carry the alias information
> from the high-level IL down to the machine-code level IL, and pipeline
> on the machine-code IL, before register allocation.

This is where SMS is currently positioned; it means that our problem is not
where SMS is performed but the alias information not getting there.  This
is exactly what we were thinking all the time; the IC example reinforces
this thought.

>
> thanks,
> Mark Davis
> Intel Compiler Lab
> (formerly with DEC compiler team)
> Nashua, NH
>

Mostafa.