On 12-11-07 5:39 PM, David Miller wrote:
Vlad, I wanted to make you aware of the following because it's
a major barrier for using LRA on sparc at this time. I therefore
do not think moving to LRA on this target is possible in the 4.8
timeframe, which is fine. The situation is described completely
in the comment I am adding in the patch below.
David, thanks very much for reporting this. I was quite surprised when
you decided to switch SPARC to LRA for gcc4.8. I was a bit scary too
because I never paid a big attention to SPARC. Even LRA for x86/x86-64
on which I worked hard is not easy to port and I have a lot of PRs now.
I did eight LRA ports on the branch mostly to prove that LRA approach is
doable to replace reload.
So your decision is a big relief for me. Thanks very much for working
on SPARC LRA port. I am sure we solve all the problems and switch on
LRA for SPARC for gcc4.9. I'll return my work on other targets and
SPARC on the branch when I am done with current LRA PRs for x86/x86-64.
The most alarming aspect of this to me was discovering that IRA could
allocate registers to a pseudo that did not pass HARD_REGNO_MODE_OK,
and this anomaly is completely masked because reload and our splitters
end up fixing things up.
I think SPARC port is far from the worst. I also found recently some
inconsistency in LRA and IRA (LRA recognizes conflicts for multi-word
pseudos when IRA does not) which I'd like to address too. I think
Richard Sandiford is probably right saying that we should use LRA as
opportunity to clean the ports.
I wanted to explicitly thank you for your work on LRA because without
it we would never have discovered these inconsistencies in the sparc
backend.
