[trunk] patch to remove REG_NO_CONFLICT_BLOCKS
Vladimir Makarov
vmakarov@redhat.com
Mon Apr 21 21:43:00 GMT 2008
Kenneth Zadeck wrote:
>
> The third patch, has a modification to ra-conflict.c to compute the
> information that is/was contained in REG_NO_CONFLICT blocks. Because
> it is computed from first principals, it actually finds cases of two
> multiword regs that could be allocated on top of each other but could
> not otherwise overlap. It also contains enhancements to global to use
> this information to do this kind of allocation. By doing this in
> global, there is now no reason to perform the allocation in
> local-alloc. Local alloc is still called but returns after
> update-equiv-regs. We have also changed things so that global is
> called for -O0. This adds .5% to the compile time, but cuts the size
> of the .o files by 5%. After peter's and my changes last year to the
> conflict builder, there really is very little compile time benefit to
> having local-alloc around.
It would be nice to remove local-alloc. But it would be not so easy to
do. Please, check c99-int-const-1.c. Even after Peter's conflict
matrix triangulation, I guess the test compilation will need 1GB memory
machine for -O0. Such big memory is not necessary for -O2. So removing
local-alloc will need to switch some optimizations on too (although I
did not analyze which ones).
Also a few years ago I did some experiments on removing local-alloc too
and I found a visible performance degradation (as I remember about 1%).
So removing local-alloc would be a bad idea without performance testing.
To be honest I don't care about local-alloc removing because I stopped
my work on improving the current register allocator long ago and put my
efforts into a new register allocator which I hope will be a default RA
soon for some architectures.
> All four patches need to be tested together, but this division makes
> it possible for different people to review the parts under their
> control. However, if some backend maintainer wanted to just review
> everything, that would great. I do want to ask that someone test
> these patches on other architectures for both correctness and
> performance.
> Comments, suggestions, attacks ....
Please, don't look at this as an attack but it would be nice to see some
performance numbers what removing REG_NO_CONFLICT_BLOCKS and byte
accurate conflict detection (without removing local-alloc) gives. I
guess there should be some improvement. I like general direction to
remove REG_NO_CONFLICT_BLOCKS and byte accurate conflict detection. I
think it is ok even it gives no visible improvement and makes compiler
a bit slower.
More information about the Gcc-patches
mailing list