Re: A GGC related question

[Vladimir Makarov <vmakarov at redhat dot com>]

On 11/22/2013, 8:04 PM, dxq wrote:
> fixing SMS,  do you mean that we only modify the SMS pass?
You don't need loop unrolling when you have a good software pipelining 
and loop vectorization.  A good software pipelining can see through any 
number of iterations and has no problems with code cache locality in 
comparison with unrolling.  A good SFP is a perfect SFP (e.g. resource 
constraints software piplening) which can deal with any loop bodies.

Unfortunately modulo scheduling deals with one BB loop body only (still 
it covers most cases after if-conversion, it is easy and can be good for 
supporting hardware with rotating regs file).  Even if the current SMS 
implementation pitfalls are fixed, there are still cases when unrolling 
could be beneficial.  So probably your approach is the best what can be 
done for now.  Also if you manage to implement the infrastructure with 
copying/backup, it could be useful for a perfect SFP implementation.  
Still I think we need long-term strategy for SFP in GCC.

> if so, the problem we have to solve:
>     * how to make unroll and sms work together? calling unroll pass in sms,
> but it would be needed more passes such as web, and it's perfect to rerun
> all the passes between unroll and sms.
>     * unroll and web pass exsit in gcc, however gcc's passes only work for a
> compilation unit, function, rather than a smaller unit we expect, loop.
> that's why we copy all global information, and rerun the passes between the
> unroll and sms sevral times.
>     * if we need try more unroll factors, copying is also needed. the backup
> exsits in single pass, so it would not be purged by GGC. but, if memory
> consuming is huge, is there any risk for the other passes? from my
> experience, when disable GGC between unroll and sms, with  ggc_min_expand =
> 100 ggc_min_heap = 20480, and compile a big file, gcc crashes down.
>      
>     That's what I can think of. you know, it's a very big and hard work. do
> you have any suggestions about our current solution?