This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster compilation speed


On Mon, Aug 12, 2002 at 04:00:08PM -0700, Geoff Keating wrote:
> My suggestion is to try shrinking RTL in other ways.  For instance,
> once RTL is generated it should all match an insn or a splitter.  If
> we could store RTL as the insn number (or a splitter number) plus the
> operands, rather than the expanded form we have now, that should be
> much easier to traverse.

I've thought about this in passing before.

> (packed_insn 15 13 17 207 {*addsi_1} [(reg:SI 61) (reg:SI 59) (reg:SI 60)])
> 
> which would save us, by my count, 50% of the RTL objects for this
> case.

A bit more than that if the packed_insn rtl is actually variable
sized so that the operands are directly at the end of the other
arguments.

> To perform operations that are now done directly on the RTL, there'd be
> a switch statement, for instance:

Another possible solution, particularly for bletcherous code like
combine, is to regenerate the full instruction on demand.  After
try_combine is done with an insn, we free it immediately so that
we don't accumulate garbage.

But I suspect that most passes don't need this.  They only need
to know which operands are inputs, sets, and clobbers.  They need
to know which predicates apply.  Information which is trivial to
generate off the md file.

This idea, I think, has real potential, and could actually be
implemented without disrupting the entire compiler.

> Even combine can be handled this way, by pregenerating rules based on
> the insn numbers being combined.  Relatively few insns can actually be
> combined, so it shouldn't require a huge amount of generated code.

Pre-generating the combinations would be really cool, and probably
save quite a bit o time, but I don't really believe in that for even
the medium term.  The number of possibilities is really quite large.

> Now, if only I could think of something that would work like this on
> trees...

Having stronger typing instead of the union-of-everything would do.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]