On Sun, Jul 8, 2012 at 9:44 PM, Steven Bosscher <stevenb....@gmail.com> wrote:
> Hello,
>
> A lot of optab_handler checks are against CODE_FOR_nothing, which is
> currently a target dependent number, the last value in "enum
> insn_code". This made target reinitializing slow, so Richard S.
> changed the optab_handler index from insn_code to (insn_code -
> CODE_FOR_nothing) to allow the table to be memset to 0 (rather than
> filling it with CODE_FOR_nothing in a loop).
>
> I didn't like this solution very much, because of the casting between
> int and enum insn_code, and because it didn't solve the problem that
> CODE_FOR_nothing is target dependent. Also, comparisons against 0 are
> cheaper on probably all targets than comparing against a larger number
> (e.g. CODE_FOR_nothing is 2414 on powerpc64, 3013 on arm, and 3852 on
> x86_64), and there are a lot of compares against CODE_FOR_nothing.
>
> Therefore I propose this patch as an alternative (and IMHO better)
> solution, that changes things such that CODE_FOR_nothing==0.
>
> To achieve this, I introduced a dummy insn in insn_data, so
> insn-output.c's insn_data now starts with:
>
> const struct insn_data_d insn_data[] =
> {
> /* <internal>:0 */
> {
> "*placeholder_for_nothing",
> #if HAVE_DESIGNATED_UNION_INITIALIZERS
> { 0 },
> #else
> { 0, 0, 0 },
> #endif
> 0,
> &operand_data[0],
> 0,
> 0,
> 0,
> 0,
> 0
> },
>
> Otherwise, there wasn't much to be changed. There was a sort-of bug in
> genpeep.c in that it was keeping its own sequence counter, but the
> rest is straight-forward.
>
> I get a small cc1 code size reduction:
> text data bss dec hex filename
> 14982747 639632 1223416 16845795 1010be3 build-patched/gcc/cc1
> 14983007 639704 1223416 16846127 1010d2f build-orig/gcc/cc1
>
> I also get a small speedup, but nothing spectacular.
>
> Bootstrapped and tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
