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?
Ciao!
Steven
rebase_CODE_FOR_nothing.diff
Description: Binary data
