This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.9 PATCH, alpha]: Switch alpha to LRA
- From: Chung-Ju Wu <jasonwucj at gmail dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Jeff Law <law at redhat dot com>, Uros Bizjak <ubizjak at gmail dot com>, Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 25 Apr 2013 16:11:11 +0800
- Subject: Re: [4.9 PATCH, alpha]: Switch alpha to LRA
- References: <CAFULd4be3azVdXQhpnQE7Qee8350480TdQM1woUnNuav3Ehw9g at mail dot gmail dot com> <51070AFC dot 9060200 at redhat dot com> <CAFULd4aYwsf2xpwbuMznNWE5q35BaCuoG=uB3UUkSvFDOVamfg at mail dot gmail dot com> <51757484 dot 4000608 at redhat dot com> <CABu31nOsM_f4mJ7cV6K8__WqBHGTCkUwHEihtyvsgbvVoG1vTw at mail dot gmail dot com> <51758CB7 dot 1070409 at redhat dot com>
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