This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL compression in GCC
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Martin Jambor <mjambor at suse dot cz>
- Cc: ALFONSO LUIS CASTANO MARIN <alfonsoluis dot castanom at um dot es>, gcc at gcc dot gnu dot org
- Date: Tue, 21 Aug 2018 10:19:08 +0100
- Subject: Re: RTL compression in GCC
- References: <20180818172242.Horde.ka3TRsfzbklw-ZSxuQn6Og1@webmail.um.es> <ri6k1olqd1c.fsf@suse.cz>
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