This is the mail archive of the gcc@gcc.gnu.org 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: RTL compression in GCC


Martin Jambor <mjambor@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


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