Re: fix opt/8634

[Geoff Keating <geoffk at geoffk dot org>]

Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz> writes:

> Hello,
> 
> > > It would also make a sense
> > > to have less memory bloated code representation (but this is of course
> > > something that cannot be changed now, and also it does not seem
> > > quite desirable).
> > 
> > It can be changed.  I can't find it now, but some time ago I wrote a
> > mail message to the GCC lists explaining how you could do everything
> > that GCC does now with RTL by using data structures that are tied to
> > specific machine instructions; for instance, instead of having
> > 
> > (jump_insn 178 177 325 (set (pc)
> >         (if_then_else (ne (reg:CC 150)
> >                 (const_int 0 [0x0]))
> >             (label_ref 231)
> >             (pc))) 541 {*rs6000.md:13889} (nil)
> >     (expr_list:REG_DEAD (reg:CC 150)
> >         (nil)))
> > 
> > you have
> > 
> > (jump_insn 178 177 325 541 {*rs6000.md:13889} (reg:CC 150) (label_ref 231)
> >   (nil) 
> >   (expr_list:REG_DEAD (reg:CC 150) (nil)) 
> >  )
> > 
> > which can be even further simplified if you notice that the first
> > parameter will always be a REG and the second a label_ref.  The
> > biggest win is not even in memory consumption, although that's pretty
> > big, it's that you don't have to traverse over all the pointers; you
> > can look at everything in this insn, other than the notes, without any
> > pointer dereferences at all.
> 
> sounds cool; still it would be quite intrusive change.

Yes, very intrusive.

>  There is quite a lot of code that traverses rtl; how would you cope
> with this? Or would all such code have to be rewritten?

In the long run, it'd have to be rewritten, generally in a simple
way.  For instance a lot of that code just wants to know things like
"which registers can this insn change", and that sort of thing can be
done efficiently by looking at the operands in conjunction with the
insn number; for instance, all insn 541s will change (pc) and look at
(pc) and their first operand.

Combine is probably the most tricky phase, since it really does look
at the RTL.  The idea for that would be to pre-generate (when building
GCC) a bunch of rules of the general form 'if an insn of type 23 has
its first operand as the second operand of a later insn of type 175,
they can be combined into an insn 177 with its first operand a MEM of
the second operand of the type-23 insn...'.  Then, combine just checks
to see if the conditions of any rule is met for each insn.  No need
for simplify_rtx, no need for insn recognition; just a match against a
table.  (Of course, simplify_rtx doesn't go away; it's still needed to
build the table from the .md files, but all that happens while the
compiler is being built, not at run-time.)

As a temporary implementation strategy, you could always re-generate
the RTL given the insn number, which would let you make the change
incrementally.  You lose some of the speed benefits that way, but not
all of them, since the memory for the temporary RTL will be re-used
over and over again so it'll always be in cache and the total
bandwidth required is reduced.

-- 
- Geoffrey Keating <geoffk at geoffk dot org>