[PATCH] Further insn-attrtab.c speedup

[Jakub Jelinek]

On Fri, Jun 18, 2010 at 04:41:26PM -0600, Jeff Law wrote:
> I'd been wondering about this class of insn-attrtab optimizations
> for a long time, probably back to the initial days of the SSA work.
> Obviously what I was worried about was the potential side effects of
> the get_attr_XXX functions since they can execute arbitrary code,
> which could include changing the form of the insn (thus changing the
> return value of subsequent calls) or something awful like setting
> global state, then querying the global state on a subsequent call.
> 
> I'm more than happy to consider any such port fundamentally broken.
> We should probably document the assumptions we make about the
> cachability of the get_attr_XXX calls.

Yeah, I'd consider any such port very much broken.  The port
doesn't have control over when exactly and how many times such get_attr_*
functions are called and e.g. genattrtab already has been doing
optimizations that assume it.  Say instead of emitting
if ((get_attr_memory (insn) == MEMORY_BOTH))
  {
    if (something && (get_attr_memory (insn) == MEMORY_BOTH))
      return 3;
    else
      return 2;
  }
else
  return 1;
vanilla genattrtab.c will emit
if ((get_attr_memory (insn) == MEMORY_BOTH))
  {
    if (something)
      return 3;
    else
      return 2;
  }
else
  return 1;
etc. (see e.g. eliminate_known_true).  So certainly
all those functions must be "pure with possible caching", definitely not
modify the the insn itself, when called second time with no code in between
must return the same value and ideally shouldn't change the global
variables at all in that case (I guess exception could be some statistics
computation, or say temporary memory allocation/freeing or GC allocation
that isn't referenced anywhere in global vars afterwards).

	Jakub