On 03/10/2019 15:15, Segher Boessenkool wrote:
On Thu, Oct 03, 2019 at 09:26:45AM -0400, Paul Koning wrote:
On Oct 3, 2019, at 9:12 AM, Richard Earnshaw (lists) <richard.earns...@arm.com>
wrote:
On 03/10/2019 10:48, Segher Boessenkool wrote:
...
But ALL_REGS should contain *all* registers. The union of any two register
classes has to be contained in some register class, so every register class
has to be contained in ALL_REGS.
Why would anyone want a to form a union of one class with a class that can't be
used for allocation. That's just silly.
Precomputations over all register classes, for example.
Yes, if that's the only purpose of register classes.
If the documentation doesn't match what the real intent is, and some developers
apparently use the intent while others use the documentation. The result is
bugs like the one we're talking about here.
It may well make sense to say that ALL_REGS should be the set of all *allocatable*
registers. If that's what we want, the documentation should say so, and then the code
has to understand that some registers (like CC_REG) may be outside ALL_REGS. Similarly,
NO_REGS is currently documented as "no registers" (empty set). If it is
intended that it might contain non-allocatable registers, again the documentation should
say so.
I doubt that works.
And ALL_REGS as *all* regs works. This is what is documented, and barring
any other evidence, also what was intended. Some other things might also
work, but even if the code works it can still be buggy.
Segher
Well if that's how tightly ALL_REGS is defined, then really no back-end
should be defining it at all. Instead the build system (or the run-time
initialization code) should be constructing it on the fly. Similarly
for NO_REGS.
R.
