This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Mainline space problem
On Aug 31, 2004, at 2:19 PM, James E Wilson wrote:
Daniel Berlin wrote:
Unless global is doing something completely weird (it may be, i
haven't looked at since i worked on new-ra), the conflict matrix is
unidirectional (IE if x conflicts with y, then y must conflict with
x).
Thus you can use a lower-triangular bitmatrix, and save half the
memory.
If we save half the memory, then we still need over a gigabyte, and we
still run out of memory. Constant factors don't help much with
quadratic problems. They are still quadratic.
You honestly believe it is not much better to use half as much memory?
That 2 gigabytes and 1 gigabyte aren't that different?
If we try using a sparse bitmaps, then we are adding unnecessary
overhead for the most common case which will make the compiler run
even slower than it already does.
What makes you think that the common case is the dense case?
It's much more likely to be sparse, otherwise 16 registers wouldn't be
enough on most platforms when there are more than 16 pseudos in a
function (and there are often hundreds).
If we try to use simple arrays for the common case, and sparse
bitmaps for the big function case, then we are adding complexity,
which will make maintenance harder.
But it is very useful in other situations as well to use a hybrid
list/bitmap structure.
I did of course consider the possibility of using some kind of sparse
matrix representation here, but I didn't think it was worth
mentioning. I think we should instead be looking at reducing the
number of pseudo regs generated for this testcase.
Sure, but that doesn't mean you should avoid improving global simply
because it might not be enough.
That would tell me you should improve global, *and* do something else.
Then you save even more memory and time.
By the way, I did try -fnew-ra. It used over 980MB and then died with
a segfault. I didn't bother looking at why, but I figured if -fnew-ra
couldn't handle it, then fixing global to handle it was probably not
feasible.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com