> Regs_ever_live is the poster child of this. In theory regs_ever_live is > easy, it is just the set of hard registers that are used. In practice > this is a disaster to keep track of because it was only updated > occasionally and its values are "randomly" changed by the backends in > totally undocumented ways. Maintaining regs_ever_live requires a lot of > special mechanism that slows down a the incremental scanning.
The history here, by the way, is that it was originally very simple and just supposed to provide a "quick and easy" way of having a conservative view of which registers *weren't* ever used. So it was set when a register might possibly be used. That was indeed easy. But then people wanted to be able to know *for sure* which registers were used, so mechanisms were added to clear it out when we knew a register *wasn't* used, which added the complexity you mention. This is a problem with a lot of the ad-hoc structures used: they were originally meant for one specific purpose and often used very locally and were reasonably well-designed for that purpose, but then were used more globally and/or for other purposes and they weren't quite so well designed for that purpose anymore, but nobody went to the troule to change them. I strongly support a new, common infrastructure that will allow all of these older structures to be replaced. But the history is important in my opinion because it means that we need to think as generally as possible and to ensure we come up with as broad a structure as possible in order both to replace the current structures, but also to support many other uses in the future. What what I understand, the current mechanism does that, but I think it's important to keep this criterion in mind when evaluating any possible "competitors".
