Re: [new-regalloc-branch] patch: subreg things 2/2

[Daniel Berlin <dan at cgsoftware dot com>]

Michael Matz <matzmich@cs.tu-berlin.de> writes:

> Hi,
> 
> although I _really_^3 should have better prepared my thesis talk tomorrow
> here finally is the second patch needed to track subreg usages more
> precisely in the allocator.  I will check it in soon.  It is now slow as
> molasses, but that is due to horrible data structures (or no structures at
> all? ;) and will be changed probably next week.  I expect that most (if
> not all) code will not run slower, and if spilling is involved at all,
> faster than before.  Of course it might not work at all on other platforms
> than x86 (where it bootstraps without regressions), esp. platforms with
> strange register file, esp. when it comes to subreg's.  Also it can only
> handle regs which are HOST_BITS_PER_WIDE_INT units wide at most (i.e. 64
> _bytes_ on many platforms at least).  I guess this all will be fairly
> easily fixable.  It can't yet color subregs on their own (i.e. parts of a
> reg spilled, other parts into hardregs), but it spills only necessary
> parts.  I'm not yet sure, if I want to take that path, or better massage
> the code before feeding it to the allocator.  Next week I probably will
> have more time than usual to work on regalloc.
> 
> Here is the changelog, and the patch should be below if I do everything
> right.
> 
> 
> Ciao,
> Michael.
> -- 

Michael,
Just FYI, I plan on getting rid of the conservative coalescing part.
Until optimistic coalescing is fully implemented, this will mainly
consist of commenting out the call to the conservative test, and
freezing of moves. (Yes, I
know if we don't do iterated conservative coalescing, we don't need the freeze
list, etc. I will clean that up when i do the live range splitting stuff.

Papers i've read and that are now popping up these days show that
aggressive coalescing on top of a Briggs style allocator (most were
comparing to aggressive coalescing on a chaitin style allocator, which
didn't delay spill decisions) does
better than iterated coalescing anyway, because the positive impact of
coalescing on most code outweighs the negative impact, by a large
factor.
My own testing on SPEC, and various random pieces of software, lead me
to the same conclusions.
We spill less, while eliminating more copies.

This has also been shown in the paper on optimistic register coalescing, among other papers.

--Dan