Martin Jambor <mjam...@suse.cz> writes: > Hello Alfonso, > On Sat, Aug 18 2018, ALFONSO LUIS CASTANO MARIN wrote: >> Dear Martin, >> >> I am interested in contributing to GCC to speed-up the compiler and I >> thought that the issues related with RTL are very interesting. I wonder if >> still there has not been done any job in RTL compression and if you could >> point me to someone how could give me some hints about how to contribute in >> this. > > I suggest you discuss any GCC development ideas on the mailing list > gcc@gcc.gnu.org > > As far as RTL compression is concerned, I do not remember it being > discussed or proposed before. From what I can tell, we are not usually > looking at RTL memory footprint when dealing with excessive memory > consumption, one reason is likely that there is only one function in the > RTL representation at a time, as opposed to the whole compilation unit > in GIMPLE. Others will surely correct me if I am wrong, however, and > may even suggest other areas where compilation speed could be improved.
FWIW, one RTL compression suggestion I remember being discussed way back when was the idea of storing only an instruction's INSN_CODE and operands and using them to reconstruct the whole RTL pattern on demand. That would have been fairly cheap to do in the old obstack-based days, but probably doesn't make as much sense now that RTL is garbage-collected. One area that seems a bit inefficient is that walking a block of insns and using their df info goes through: #define DF_INSN_INFO_GET(INSN) (df->insns[(INSN_UID (INSN))]) for every instruction. When profiling GCC in the past I've seen this be a significant source of cache misses. It might be more efficient to store the DF info in the instruction itself, in a similar way to block_symbol for SYMBOL_REF, but it's hard to say without trying it and measuring. I agree that other areas might be more important these days though. Thanks, Richard
