This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Implement smart multiple switch expansion algorithms.
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "mliska at suse dot cz" <mliska at suse dot cz>
- Cc: nd <nd at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Fri, 6 Oct 2017 13:46:17 +0000
- Subject: Re: [PATCH] Implement smart multiple switch expansion algorithms.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Martin Liska wrote:
> There are some numbers for cc1plus:
>
> $ bloaty ./objdir2/gcc/cc1plus -- ./objdir/gcc/cc1plus
> VM SIZE FILE SIZE
> +3.8% +1.11Mi TOTAL +1.03Mi +0.5%
> insn-attrtab.o:
> VM SIZE FILE SIZE
> +214% +682Ki .rodata +682Ki +214%
> -50.1% -63.3Ki .text -63.3Ki -50.1%
So is that a 3.8% codesize increase or decrease? If an increase,
I can't see how replacing 63KB of instructions with 682KB of data
is a good tradeoff... There should be an accurate calculation
of the density, taking the switch table width into account (really small
tables can use 1-byte offsets, large tables are typically forced to
use 4-byte offsets). This may need new target callbacks - I changed
PARAM_CASE_VALUES_THRESHOLD on AArch64 to get smaller
code and better performance since the current density calculations
are hardcoded and quite wrong for big tables...
Also what is the codesize difference on SPEC2006/2017? I don't see
any mention of performance impact either...
Wilco