[4.9 PATCH, alpha]: Switch alpha to LRA

[4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

Hello!

2013-01-28  Uros Bizjak  <ubizjak@gmail.com>

	* config/alpha/alpha.c (TARGET_LRA_P): New define.

Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.

OK for 4.9?

[1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02998.html

Uros.

Index: config/alpha/alpha.c
===================================================================
--- config/alpha/alpha.c        (revision 195502)
+++ config/alpha/alpha.c        (working copy)
@@ -9872,6 +9872,9 @@
 #undef TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p

+#undef TARGET_LRA_P
+#define TARGET_LRA_P hook_bool_void_true
+
 #undef TARGET_CONDITIONAL_REGISTER_USAGE
 #define TARGET_CONDITIONAL_REGISTER_USAGE alpha_conditional_register_usage

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Richard Henderson]

On 01/28/2013 03:14 PM, Uros Bizjak wrote:
> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>
> 	* config/alpha/alpha.c (TARGET_LRA_P): New define.
>
> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>
> OK for 4.9?
>

Yep.


r~

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Jeff Law]

On 01/28/2013 04:14 PM, Uros Bizjak wrote:
> Hello!
>
> 2013-01-28  Uros Bizjak  <ubizjak@gmail.com>
>
> 	* config/alpha/alpha.c (TARGET_LRA_P): New define.
>
> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>
> OK for 4.9?
>
> [1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02998.html
Can you attach this to PR 55996, the 4.9 pending patches metabug.

Thanks,
jeff

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com> wrote:
> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>
>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>
>>         * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>
>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>
>> OK for 4.9?
>>
>
> Yep.

Unfortunately, alphas are much more tied to reload than it was hoped.
While latest alphas (with FIX and BWX ISAs) survived transition to LRA
without problems, further testing on ev4 and ev5 triggered various
problems, one of them is PR57032 [1] that exposed rather unique way of
handling aligned/nonaligned memory operands.

The patch was reverted.

I suspect that fixing older alphas to live with LRA would be quite
involved task, and I guess nobody (including me) wants to spend
considerable amount of time on a dying architecture. Consequently,
this also means that alphas will die together with reload as far as
gcc is concerned.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032

Uros.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Jeff Law]

On 04/22/2013 11:17 AM, Uros Bizjak wrote:
> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com> wrote:
>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>>
>>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>>
>>>          * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>
>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>
>>> OK for 4.9?
>>>
>>
>> Yep.
>
> Unfortunately, alphas are much more tied to reload than it was hoped.
> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
> without problems, further testing on ev4 and ev5 triggered various
> problems, one of them is PR57032 [1] that exposed rather unique way of
> handling aligned/nonaligned memory operands.
>
> The patch was reverted.
>
> I suspect that fixing older alphas to live with LRA would be quite
> involved task, and I guess nobody (including me) wants to spend
> considerable amount of time on a dying architecture. Consequently,
> this also means that alphas will die together with reload as far as
> gcc is concerned.
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
Would it make sense to deprecate the older Alpha implementations without 
killing the "modern" ones?

jeff

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law <law@redhat.com> wrote:

>> Unfortunately, alphas are much more tied to reload than it was hoped.
>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>> without problems, further testing on ev4 and ev5 triggered various
>> problems, one of them is PR57032 [1] that exposed rather unique way of
>> handling aligned/nonaligned memory operands.
>>
>> The patch was reverted.
>>
>> I suspect that fixing older alphas to live with LRA would be quite
>> involved task, and I guess nobody (including me) wants to spend
>> considerable amount of time on a dying architecture. Consequently,
>> this also means that alphas will die together with reload as far as
>> gcc is concerned.
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>
> Would it make sense to deprecate the older Alpha implementations without
> killing the "modern" ones?

Looking at [1], I would propose a cutoff point at ev6.

IIUC, the core of the problem is with *movdi, *movhi and *movqi
patterns, where moves to/from memory are blocked for FP (there remains
"Q" constraint in the *movdi case, ignored by LRA) and integer regs.
This situation gets eventually fixed during reload (please see various
instances of reload_in_progress), which is somehow incompatible with
LRA.

[1] http://en.wikipedia.org/wiki/DEC_Alpha

Uros.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Steven Bosscher]

On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>
>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com>
>> wrote:
>>>
>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>>>
>>>>
>>>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>>>
>>>>          * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>>
>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>>
>>>> OK for 4.9?
>>>>
>>>
>>> Yep.
>>
>>
>> Unfortunately, alphas are much more tied to reload than it was hoped.
>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>> without problems, further testing on ev4 and ev5 triggered various
>> problems, one of them is PR57032 [1] that exposed rather unique way of
>> handling aligned/nonaligned memory operands.
>>
>> The patch was reverted.
>>
>> I suspect that fixing older alphas to live with LRA would be quite
>> involved task, and I guess nobody (including me) wants to spend
>> considerable amount of time on a dying architecture. Consequently,
>> this also means that alphas will die together with reload as far as
>> gcc is concerned.
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>
> Would it make sense to deprecate the older Alpha implementations without
> killing the "modern" ones?

Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
target/56858).

I think it would be a shame to not enable LRA on alpha. It will only
be another excuse to never let reload die, and it will hurt stability
and reliability for Alpha EV6 in the long term as other targets switch
over to LRA.

Is it possible to add some EV4/EV5 splitters to work around this Alpha
EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
still better than tying the fate of apha to reload and vice versa..

Ciao!
Steven

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Vladimir Makarov]

On 13-04-22 2:19 PM, Steven Bosscher wrote:
> On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
>> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com>
>>> wrote:
>>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>>>>
>>>>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>>>>
>>>>>           * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>>>
>>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>>>
>>>>> OK for 4.9?
>>>>>
>>>> Yep.
>>>
>>> Unfortunately, alphas are much more tied to reload than it was hoped.
>>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>>> without problems, further testing on ev4 and ev5 triggered various
>>> problems, one of them is PR57032 [1] that exposed rather unique way of
>>> handling aligned/nonaligned memory operands.
>>>
>>> The patch was reverted.
>>>
>>> I suspect that fixing older alphas to live with LRA would be quite
>>> involved task, and I guess nobody (including me) wants to spend
>>> considerable amount of time on a dying architecture. Consequently,
>>> this also means that alphas will die together with reload as far as
>>> gcc is concerned.
>>>
>>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>> Would it make sense to deprecate the older Alpha implementations without
>> killing the "modern" ones?
> Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
> target/56858).
>
> I think it would be a shame to not enable LRA on alpha. It will only
> be another excuse to never let reload die, and it will hurt stability
> and reliability for Alpha EV6 in the long term as other targets switch
> over to LRA.
>
> Is it possible to add some EV4/EV5 splitters to work around this Alpha
> EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
> still better than tying the fate of apha to reload and vice versa..
>
>
I never tried alpha with LRA.  So it is not assumed that LRA should work 
on alpha.  But I am sure LRA can work for alpha if some efforts will be 
spent.  Porting LRA to a new target always involves changes in .md and 
machine-dependent files.  This process was even not started.

Actually, Uros showed that Alpha will not require a lot of efforts as 
code in most cases is  already generated successfully.  I don't remember 
any target which I tried to port LRA in such a good shape at the 
beginning of LRA port process.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>
> I never tried alpha with LRA.  So it is not assumed that LRA should work on
> alpha.  But I am sure LRA can work for alpha if some efforts will be spent.
> Porting LRA to a new target always involves changes in .md and
> machine-dependent files.  This process was even not started.
>
> Actually, Uros showed that Alpha will not require a lot of efforts as code
> in most cases is  already generated successfully.  I don't remember any
> target which I tried to port LRA in such a good shape at the beginning of
> LRA port process.

Vladimir, thanks for encouraging words, it looks that all hope is not
lost yet. However, I would like to point out that I have tested only
ev68 architecture, and apparently all the interesting stuff is in the
way ev4 and ev5 are handled. I can certainly spend a reasonable time
to bring the port up to life, but for now, I propose to revert the
patch, until ev4 bootstrap is fixed.

Uros.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Vladimir Makarov]

On 13-04-22 3:35 PM, Uros Bizjak wrote:
> On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>> I never tried alpha with LRA.  So it is not assumed that LRA should work on
>> alpha.  But I am sure LRA can work for alpha if some efforts will be spent.
>> Porting LRA to a new target always involves changes in .md and
>> machine-dependent files.  This process was even not started.
>>
>> Actually, Uros showed that Alpha will not require a lot of efforts as code
>> in most cases is  already generated successfully.  I don't remember any
>> target which I tried to port LRA in such a good shape at the beginning of
>> LRA port process.
> Vladimir, thanks for encouraging words, it looks that all hope is not
> lost yet. However, I would like to point out that I have tested only
> ev68 architecture, and apparently all the interesting stuff is in the
> way ev4 and ev5 are handled. I can certainly spend a reasonable time
> to bring the port up to life, but for now, I propose to revert the
> patch, until ev4 bootstrap is fixed.
>
>
Sure, Uros.  I agree.  Thanks for trying alpha.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Chung-Ju Wu]

2013/4/23 Steven Bosscher <stevenb.gcc@gmail.com>:
> On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
>> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>>
>>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com>
>>> wrote:
>>>>
>>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>>>>
>>>>>
>>>>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>>>>
>>>>>          * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>>>
>>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>>>
>>>>> OK for 4.9?
>>>>>
>>>>
>>>> Yep.
>>>
>>>
>>> Unfortunately, alphas are much more tied to reload than it was hoped.
>>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>>> without problems, further testing on ev4 and ev5 triggered various
>>> problems, one of them is PR57032 [1] that exposed rather unique way of
>>> handling aligned/nonaligned memory operands.
>>>
>>> The patch was reverted.
>>>
>>> I suspect that fixing older alphas to live with LRA would be quite
>>> involved task, and I guess nobody (including me) wants to spend
>>> considerable amount of time on a dying architecture. Consequently,
>>> this also means that alphas will die together with reload as far as
>>> gcc is concerned.
>>>
>>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>>
>> Would it make sense to deprecate the older Alpha implementations without
>> killing the "modern" ones?
>
> Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
> target/56858).
>
> I think it would be a shame to not enable LRA on alpha. It will only
> be another excuse to never let reload die, and it will hurt stability
> and reliability for Alpha EV6 in the long term as other targets switch
> over to LRA.
>
> Is it possible to add some EV4/EV5 splitters to work around this Alpha
> EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
> still better than tying the fate of apha to reload and vice versa..
>
> Ciao!
> Steven


How about using follow constraints?

Index: alpha.c
===================================================================
--- alpha.c     (revision 198216)
+++ alpha.c     (working copy)
@@ -9871,6 +9871,9 @@
 #undef TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p

+#undef TARGET_LRA_P
+#define TARGET_LRA_P hook_bool_void_true
+
 #undef TARGET_CONDITIONAL_REGISTER_USAGE
 #define TARGET_CONDITIONAL_REGISTER_USAGE alpha_conditional_register_usage

Index: alpha.md
===================================================================
--- alpha.md    (revision 198216)
+++ alpha.md    (working copy)
@@ -4073,9 +4073,9 @@

 (define_insn "*movdi"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-                               "=r,r,r,r,r,r,r,r, m, *f,*f, Q, r,*f")
+                               "=r,r,r,r,r,r,r,r, m, *f,*f, m, r,*f")
        (match_operand:DI 1 "input_operand"
-                               "rJ,K,L,T,s,n,s,m,rJ,*fJ, Q,*f,*f, r"))]
+                               "rJ,K,L,T,s,n,s,m,rJ,*fJ, m,*f,*f, r"))]
   "register_operand (operands[0], DImode)
    || reg_or_0_operand (operands[1], DImode)"
   "@


As Uros said, the 'Q' is ignored by LRA.
The reason is that the predicate function normal_memory_operand()
may change op to a memory location by using resolved_reload_operand().
However, if LRA is enabled, resolve_reload_operand() always returns
original reg op because reload_in_progress would never be true,
resulting reload loop in this case.

So I guess using 'm' constraint instead of 'Q' is able to avoid
such abnormal behavior, leaving all the reload jobs to LRA.
IMHO that is a simplest solution.  At least it passes the case in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
and successfully build libgcc.


Best regards,
jasonwucj

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Chung-Ju Wu]

2013/4/23 Vladimir Makarov <vmakarov@redhat.com>:
> On 13-04-22 2:19 PM, Steven Bosscher wrote:
>>
>> On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
>>>
>>> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>>>
>>>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <rth@redhat.com>
>>>> wrote:
>>>>>
>>>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>>>>>
>>>>>>
>>>>>> 2013-01-28  Uros Bizjak<ubizjak@gmail.com>
>>>>>>
>>>>>>           * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>>>>
>>>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>>>>
>>>>>> OK for 4.9?
>>>>>>
>>>>> Yep.
>>>>
>>>>
>>>> Unfortunately, alphas are much more tied to reload than it was hoped.
>>>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>>>> without problems, further testing on ev4 and ev5 triggered various
>>>> problems, one of them is PR57032 [1] that exposed rather unique way of
>>>> handling aligned/nonaligned memory operands.
>>>>
>>>> The patch was reverted.
>>>>
>>>> I suspect that fixing older alphas to live with LRA would be quite
>>>> involved task, and I guess nobody (including me) wants to spend
>>>> considerable amount of time on a dying architecture. Consequently,
>>>> this also means that alphas will die together with reload as far as
>>>> gcc is concerned.
>>>>
>>>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>>>
>>> Would it make sense to deprecate the older Alpha implementations without
>>> killing the "modern" ones?
>>
>> Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
>> target/56858).
>>
>> I think it would be a shame to not enable LRA on alpha. It will only
>> be another excuse to never let reload die, and it will hurt stability
>> and reliability for Alpha EV6 in the long term as other targets switch
>> over to LRA.
>>
>> Is it possible to add some EV4/EV5 splitters to work around this Alpha
>> EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
>> still better than tying the fate of apha to reload and vice versa..
>>
>>
> I never tried alpha with LRA.  So it is not assumed that LRA should work on
> alpha.  But I am sure LRA can work for alpha if some efforts will be spent.
> Porting LRA to a new target always involves changes in .md and
> machine-dependent files.  This process was even not started.
>
> Actually, Uros showed that Alpha will not require a lot of efforts as code
> in most cases is  already generated successfully.  I don't remember any
> target which I tried to port LRA in such a good shape at the beginning of
> LRA port process.
>

I would like to share a little bit of my thought. :)

We are porting a 32-bit target, 'nds32', for GCC
since gcc-4.6, 4.7, and 4.8/trunk.
During these years we experienced implementation
trade-off between reload and LRA.

Solving register allocation is NP-complete (coloring problem).
Reload is further to fix up any unsatisfied operands in the instruction
and trying to do everything at once.  It is powerful, yet complicated.
Numbers of target hooks/macros make us confused and hard to implement.
LRA, however, its systematic design and clear flow
make developers easy to use and trace code.
The instruction constraints become primary source of the information.
Even some rookie-GCC-developers like me or my team members
are also capable of identifying potential allocation issues
when developing a new target.
(See Shiva Chen's patch
 http://gcc.gnu.org/ml/gcc/2013-04/msg00225.html
 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01350.html)

Eventually we decide to enable LRA in our 'nds32' porting.
So I believe porting a new target costs less efforts with LRA
than that with reload.  For existing targets, of course,
the efforts depend on how tight it is to reload. :p


Best regards,
jasonwucj

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Thu, Apr 25, 2013 at 10:04 AM, Chung-Ju Wu <jasonwucj@gmail.com> wrote:

>>>>>>          * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>>>>>
>>>>>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>>>>>
>>>>>> OK for 4.9?
>>>>>>
>>>>>
>>>>> Yep.
>>>>
>>>>
>>>> Unfortunately, alphas are much more tied to reload than it was hoped.
>>>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>>>> without problems, further testing on ev4 and ev5 triggered various
>>>> problems, one of them is PR57032 [1] that exposed rather unique way of
>>>> handling aligned/nonaligned memory operands.
>>>>
>>>> The patch was reverted.
>>>>
>>>> I suspect that fixing older alphas to live with LRA would be quite
>>>> involved task, and I guess nobody (including me) wants to spend
>>>> considerable amount of time on a dying architecture. Consequently,
>>>> this also means that alphas will die together with reload as far as
>>>> gcc is concerned.
>>>>
>>>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>>>
>>> Would it make sense to deprecate the older Alpha implementations without
>>> killing the "modern" ones?
>>
>> Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
>> target/56858).
>>
>> I think it would be a shame to not enable LRA on alpha. It will only
>> be another excuse to never let reload die, and it will hurt stability
>> and reliability for Alpha EV6 in the long term as other targets switch
>> over to LRA.
>>
>> Is it possible to add some EV4/EV5 splitters to work around this Alpha
>> EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
>> still better than tying the fate of apha to reload and vice versa..
>>
>> Ciao!
>> Steven
>
>
> How about using follow constraints?
>
> Index: alpha.c
> ===================================================================
> --- alpha.c     (revision 198216)
> +++ alpha.c     (working copy)
> @@ -9871,6 +9871,9 @@
>  #undef TARGET_LEGITIMATE_ADDRESS_P
>  #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p
>
> +#undef TARGET_LRA_P
> +#define TARGET_LRA_P hook_bool_void_true
> +
>  #undef TARGET_CONDITIONAL_REGISTER_USAGE
>  #define TARGET_CONDITIONAL_REGISTER_USAGE alpha_conditional_register_usage
>
> Index: alpha.md
> ===================================================================
> --- alpha.md    (revision 198216)
> +++ alpha.md    (working copy)
> @@ -4073,9 +4073,9 @@
>
>  (define_insn "*movdi"
>    [(set (match_operand:DI 0 "nonimmediate_operand"
> -                               "=r,r,r,r,r,r,r,r, m, *f,*f, Q, r,*f")
> +                               "=r,r,r,r,r,r,r,r, m, *f,*f, m, r,*f")
>         (match_operand:DI 1 "input_operand"
> -                               "rJ,K,L,T,s,n,s,m,rJ,*fJ, Q,*f,*f, r"))]
> +                               "rJ,K,L,T,s,n,s,m,rJ,*fJ, m,*f,*f, r"))]
>    "register_operand (operands[0], DImode)
>     || reg_or_0_operand (operands[1], DImode)"
>    "@
>
>
> As Uros said, the 'Q' is ignored by LRA.
> The reason is that the predicate function normal_memory_operand()
> may change op to a memory location by using resolved_reload_operand().
> However, if LRA is enabled, resolve_reload_operand() always returns
> original reg op because reload_in_progress would never be true,
> resulting reload loop in this case.
>
> So I guess using 'm' constraint instead of 'Q' is able to avoid
> such abnormal behavior, leaving all the reload jobs to LRA.
> IMHO that is a simplest solution.  At least it passes the case in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
> and successfully build libgcc.

Yes, this patch will work up to building libstdc++, where it will fail
with the same reason on movqi pattern (on non-BWX target). I suspect
that QImode access is generated during LRA (where reload_in_progress
is false!) and it directly generates movqi, which can't use memory
operand. Maybe simply adding lra_in_progress to reload_in_progress
would fix this problem.

Uros.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Richard Henderson]

On 2013-04-25 09:18, Uros Bizjak wrote:
> Yes, this patch will work up to building libstdc++, where it will fail
> with the same reason on movqi pattern (on non-BWX target). I suspect
> that QImode access is generated during LRA (where reload_in_progress
> is false!) and it directly generates movqi, which can't use memory
> operand. Maybe simply adding lra_in_progress to reload_in_progress
> would fix this problem.

Possibly.

I've wondered in the past if it wouldn't be better to spill
QI/HImode values in SImode for pre-BWX targets.  Back in the
day that would have involved hacking reload, but now it would
appear that SECONDARY_MEMORY_NEEDED_RTX plus a reload_[qh]i
pattern would do the job.

Of course, that macro itself is in reload.c... Is there some
other way we're supposed to get the same effect from LRA?


r~