[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: IA-64 GCC deprecation?



On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> I know that argument and I have heard it before but whenever I asked
> for a particular example which code in question of a backend would
> block something else, I never received an answer.

It is hard to produce good examples on demand, as some of these things
tend to be temporary problems, and someone just gets impatient enough
that they just make a blind fix to the targets that can't be properly
tested.

A possible example here is LRA.  This is a new local register
allocation pass that is intended to replace the very old reload pass.
For now, some ports are continuing to use reload.  Some ports are
using LRA.  Generally, the well maintained ports are using LRA because
it has a number of advantages, and the poorly maintained ports are
still using reload.  We would like to eventually obsolete the reload
code, but we can't do that until every port switches over.  Meanwhile,
we have to maintain two very different register allocation passes that
do the same thing, which is twice as much work as only having one of
them.  So we'd really like to see all ports switch over to LRA.  IA-64
is one of the ports that hasn't switched yet.  Most of the unfixed
ports are embedded targets, and eventually someone will get impatient
enough to fix them even though they don't care about the target, using
a simulator to test it.  But IA-64 is a server part, not an embedded
part, so in theory requires more testing.  Also, there is no free
simulator for IA-64 that I know of which makes the testing harder.
However, there are over 20 targets that don't have LRA support yet, so
the IA-64 port is not a blocking factor here yet.  There are people
slowly converting random embedded ports over though, so eventually
IA-64 will be a blocking factor if it doesn't get fixed.

Jim


Reply to: