Re: Patch to define __NO_STRING_INLINES in system.h

[Jan Hubicka <jh at suse dot cz>]

> Daniel Berlin <dberlin@dberlin.org> writes:
> >> 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.
> >
> > When i resurrected this patch a year or so ago  (after you sent it to
> > me, if you don't remember), I got it working somewhat, and *did*
> > notice a performance difference, so i gave up on it.
> 
> I don't believe I heard back from you about it at any point, so I'd
> forgotten I'd done that.  A performance difference surprises me - I
> couldn't persuade gcc to spend any measurable time in recog() when I
> was experimenting with it.  We'll see what happens this time round.

It may be because of trashing code cache.  When I did some oprofiling of
GCC there has been wast majority of code cache faults in code
surrounding recog and get_attr calls.  I think that for instance
constrain_operands is overestimated in the profiles because of that.

Having insn_recog and insn_attrtab bytecoded would be truly great!

Honza
> 
> zw