Re: gcc/resource.c mark_target_live_regs Question

[Brad Lucier <lucier at math dot purdue dot edu>]

> From mitchell@codesourcery.com  Fri Feb 16 11:40:52 2001
> 
> >>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:
> 
>     Brad> I'm not exactly understanding all the implications of this
>     Brad> discussion, but one easily gets > 200 instructions in the
>     Brad> inner basic block of a 8-way butterfly FFT code used for
>     Brad> bignum multiplication, and I wouldn't want all registers
>     Brad> marked as live in that block.
> 
> We're talking about this in the context of delay-slot filling.

OK, thanks for the explanation.

> Bottom line: you're often concerned about compile-time performance on
> machine-generated code, and this is one of the problematic places.
> With better algorithsm, we could run faster and generate better code
> -- but that's not going to happen right now, so we might as well bring
> the compile-times into a reasonable range.  Plus, with the new --param
> stuff, you can always crank this all the way back up if you want.

I'm all for compile-time performance, especially in places where it
takes > 10 times longer than it should take (or than it took earlier).
But I'm most definitely *not* in favor of achieving compile-time
performance by using quadratic (or worse) algorithms and then putting
artificial limiters on the amount of input data considered.

Brad