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 <r...@redhat.com>
wrote:
On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjak<ubiz...@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.
