This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A GGC related question

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]