This is the mail archive of the
mailing list for the GCC project.
Re: A Question About LRA/reload
- From: lin zuojian <manjian2006 at gmail dot com>
- To: Kugan <kugan dot vivekanandarajah at linaro dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 9 Dec 2014 18:34:30 +0800
- Subject: Re: A Question About LRA/reload
- Authentication-results: sourceware.org; auth=none
- References: <20141209093747 dot GA25618 at ubuntu> <5486CA2E dot 1060006 at linaro dot org> <20141209101429 dot GB25618 at ubuntu>
Moreover, LRA assignment does not refer to the assignment result of ira
directly. In find_hard_regno_for, the value of hard_regno comes from
ira_class_hard_regs[rclass][i] with least cost.
On Tue, Dec 09, 2014 at 06:14:29PM +0800, lin zuojian wrote:
> Hi Kugan,
> I have read these pdfs. My question is LRA will change the insns, so
> why brother do the coloring so early. Changing the insns can
> generates new pseudo registers, so they needs to re-assign. Is that
> Thanks Kugan
> On Tue, Dec 09, 2014 at 09:08:46PM +1100, Kugan wrote:
> > On 09/12/14 20:37, lin zuojian wrote:
> > > Hi,
> > > I have read ira/lra code for a while, but still fails to understand
> > > their relationship. The main question is why ira do color so early?
> > > lra pass will do the assignment anyway. Sorry if I mess up coloring
> > > and hard register assignment, but I think it's better to get job
> > > done after lra elimiation, inheriation, ...
> > IRA does the register allocation and LRA matches insn constraints.
> > Therefore IRA has to do the coloring. LRA, in the process matching
> > constraints may change some of these assignment. Please look at the
> > following links for more info.
> > https://ols.fedoraproject.org/GCC/Reprints-2007/makarov-reprint.pdf
> > https://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=Local_Register_Allocator_Project_Detail.pdf
> > Thanks,
> > Kugan