[patch] Rebase insn data to make CODE_FOR_nothing == 0, revert r161809

[Richard Guenther]

On Sun, Jul 8, 2012 at 9:44 PM, Steven Bosscher <stevenb.gcc@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