This is the mail archive of the
mailing list for the GCC project.
Re: [4.9 PATCH, alpha]: Switch alpha to LRA
- From: Jeff Law <law at redhat dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Mon, 22 Apr 2013 11:33:56 -0600
- 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>
On 04/22/2013 11:17 AM, Uros Bizjak wrote:
Would it make sense to deprecate the older Alpha implementations without
killing the "modern" ones?
On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson <firstname.lastname@example.org> wrote:
On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjak<email@example.com>
* config/alpha/alpha.c (TARGET_LRA_P): New define.
Bootstrapped and regression tested  on alphaev68-unknown-linux-gnu.
OK for 4.9?
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  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.