regrename speedup

[Eric Botcazou]

> The following patch cures the problem entirely.  The initial scanning
> phase of the renamer is rewritten to keep track of conflicts between
> chains, as well as recording lifetimes of hard registers.  This removes
> the need for merge_overlapping_regs to rescan the basic block every time.

What's the effect on the memory consumption, e.g. for the testcase of PR38582?

> I've bootstrapped and regression tested this patch on i686-linux with
> another small patch to force flag_rename_registers to 1.
>
> Ok (and for which stage)?

I think we should consider installing it now, given that the option is only 
activated on demand or through -funroll-loops and -fpeel-loops.

I have a request though: can you split the patch into 2 parts, the first one 
containing only the cleaning and refactoring work?  That is to say, primarily 
the hide_operands/restore_operands thing.  But could you also add the removal 
of the unused earlyclobber machinery?  Your patch won't use it either and the 
combined result is a little confusing.  Thanks in advance.

-- 
Eric Botcazou