On Thu, Jun 13, 2019 at 1:35 PM John Paul Adrian Glaubitz <[email protected]> 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
