This is the mail archive of the
mailing list for the GCC project.
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 07 May 2009 15:32:46 -0400
- Subject: Re: CONSTRAINT__LIMIT
- References: <firstname.lastname@example.org> <49ED3B9F.email@example.com> <200905050203.n45239Wn030322@greed.delorie.com>
DJ Delorie wrote:
A lot of ports can use this code. But the code is used only for
priority coloring which is not default for most ports. The code itself
could result in better priority coloring.
Ian, thanks for reporting this. I'll investigate this more. It
affects only ports using priority allocation (I know only one which
is m32c). DJ just recently reported a reload failure problem on
m32c. Probably that is because of this wrong code.
In checking through this code, I see that it depends on having
define_constraint's in the *.md file. m32c has none, so this code is
not triggered. Has any port ever used this code?
Would the lack of
define_constraints be causing problems for the m32c backend?
It is hard to tell me. I guess IRA just triggered some m32c problems.
So the code might untrigger them. But I am not sure. In general,
whatever allocation (or no allocation at all) is done by RA, reload
should generate a correct (although may be a bad) code.
I got some impression that the problem with ports is that cost macros
(e.g. REGISTER_MOVE_COST) not defined for all register classes. But
usually they are defined correctly for register classes mentioned in
machine descriptions (and usually in define_constraint). If there were
no such code, register costs for priority coloring could be wrong with a
bigger chance. As an example, if there were no such code, x86 (32-bit
code) could use LEGACY_REGS (or even INDEX_REGS) instead of GENERAL_REGS
for priority coloring because they contain the same hard registers
available for allocation. It is lucky that the costs are defined right
for all these classes. And this is not true for all ports.
What I see m32c has a few register classes which are equivalent with the
point of RA because contain the same hard registers available for
allocation. I am not sure that the costs are defined correctly for all
classes. So adding define_constraints might help in better RA based on
priority coloring (it is the single algorithm available for m32c) but
probably will not help in generation of the correct code.