Patch to define __NO_STRING_INLINES in system.h

[Jan Hubicka]

> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> 
> >  > Yes.  1.5k is trivial - I've got a patch under development to knock
> >  > the text size down by ~200k.  And that's an easy one; there's more
> >  > gains to be had in the same places.
> >
> > Ok now I'm curious.  Please do tell.
> 
> Three of the six largest object files in an ix86 build are generated
> code:
> 
>  167060       0       0  167060   28c94 insn-emit.o
>  172120       0     108  172228   2a0c4 cp/pt.o
>  207807       0     404  208211   32d53 cp/decl.o
>  224379       0       0  224379   36c7b insn-recog.o
>  344458      16    4600  349074   55392 java/parse.o
>  367201       8     780  367989   59d75 insn-attrtab.o
> 
> insn-recog.c contains a giant decision tree all spelled out in C.
> Back in 1999 rth and I got about halfway done with a patch to
> implement it using a bytecode interpreter instead.  This gave ~10x
> size reduction and no measurable performance difference.  That's the
> patch I'm working on again now.
> 
> I've never been able to figure out exactly how genattrtab works, but
> the attribute part of the code in insn-attrtab.c looks like it ought
> to be amenable to the same treatment.  It wouldn't help much with the

One problem may be that attributes allows symbol_ref construction that
actually contain arbitary C code that is put trought.
But perhaps that can be done using separate eavulator function for each
atomic element including different symbol_refs.
Except for that it is just executing expressions that are previously
encoded in RTL.  They may be boolean, strings, integers and probably few
other types.
Writing intepreter for that is definitly not impossible, question is how
effective it would be.  In the past we've spent measurable amounts of
time in get_attr stuff.  In case we get it 5 times slower it can be
serious.
It also may be possible to go half way and write interpreter of boolean
operations and keep all the rest in C.

Honza