This is the mail archive of the
mailing list for the GCC project.
Re: LRA Stuck in a loop until aborting
- From: Richard Henderson <rth at redhat dot com>
- To: pshortis at dataworx dot com dot au, gcc at gcc dot gnu dot org
- Date: Wed, 16 Apr 2014 15:19:23 -0700
- Subject: Re: LRA Stuck in a loop until aborting
- Authentication-results: sourceware.org; auth=none
- References: <fc847518922f9baf6394b7982d05edce at dataworx dot com dot au> <534EFEB4 dot 40407 at dataworx dot com dot au>
On 04/16/2014 03:05 PM, Paul Shortis wrote:
> Solved... kind of.
> *ldsi is one of the patterns movsi is expanded to and as the name suggests it
> only handles register loads. I know that at some stages memory references will
> pass the register_operand predicate so I changed the predicate for operand 0
> and added an alternative to *ldsi that could store to memory and the problem
> went away.
> What is interesting is that when LRA is disabled this case was handled fine by
> the old reload pass, suggesting that the new LRA pass handles this situation
> differently - or not at all ?
No, old reload didn't handle this either. That you got away with it is bizzare.
It's always the case that you should combine patterns such that a given
operation can be performed with as many different kinds of inputs and outputs
as possible. This allows the register allocator freedom to move data around as
it sees fit.
But the move patterns are especially special, in that a *single* pattern must
describe *all* possible ways that a given data type (mode) can be moved around.
The register allocators only select an alternative for a move. They do not
choose between N different patterns, separately describing loads, stores, and
I'm fairly sure the documentation is quite clear on this, and GCC had required
this since the beginning of time.