This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IRA for GCC 4.4


Steven Bosscher wrote:
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <mark@codesourcery.com> wrote:
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?

I think he already has explained, see http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html

Having looked at IRA a bit, I think I have to agree with Vlad that
Peter's code is not easily adapted to IRA.  Peter's code works for a
single, immutable conflict graph for the whole function.  IRA works
with inter-region and intra-region conflicts (as far as I understand,
documentation in ira-conflict.c would be welcome), so the sorting
trick that Peter uses, doesn't translate one-to-one to Vlad's
allocator.

Thanks, Steven. It is really harder to incorporate. Also, using live ranges potentially results in more compact bit vectors. I forgot to say that conflict bit vectors and adjacency lists (vector of pointers to conflict allocnos) in IRA contains only allocno of the same cover classes. I can use the fact and compress conflict vectors even more.
Having said that, I think the "square" approach with
mirror_conflicts() that IRA currently has, is a big step backward from
what we have now.  IRA should at least have a representation for
conflicts that does not duplicate information unnecessary.  The bits
that seem to be bad in this respect are build_conflict_bit_table() and
mirror_conflicts().  It's not clear to me how these are used, but it
looks like you can end up building a square conflict graph for the
whole function, like GCC did before Peter's work.  This could be a
huge memory and speed regression if it isn't addressed.

It will be addressed (I am working on this). There will be no mirror conflicts anymore. But I don't use and I am not going to use triangular matrix. It means more memory from one point of view. On other had, It permits me to use conflict bit vector for implementation of adjacency lists (and not allocate vector of pointers to conflict allocnos saving memory) if the conflict bit vector is smaller than vectors of the pointers.
Another note: IRA uses VARRAYs, and I was under the impression we are
trying to move away from those. Vlad, please use VECs instead.
Steven, thanks for pointing this. I'll remove VARRAYs. It is probably code which was written long ago. I tried to use VECs in more fresh code.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]