Increasing TargetRegisterInfo::FirstVirtualRegister?

Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister
to something quite a bit larger - such as 2^31? I'm working on a target
where all SSA values need to be assigned physical registers, and the
current limit of 16384 may limit the size of programs that I'm able to
handle. 2^31 is a nice value since there are equal numbers of possible
physical and virtual registers, and registers can just inspect the high
bit to determine if it's a virtual register. My only concern is that
there may be data structures using FirstVirtualRegister to size tables
rather than using the MachineRegisterInfo limit.

Along with this change, I would also propose subtracting
FirstVirtualRegister from the printed values of virtual registers, so that
what used to be "reg16384" would now show up as "reg0".

Andrew

If you're interested in doing this, I'd suggest hacking up the backend to not run register allocation, and represent all your "physical" registers are virtual registers. This gives you an unlimited number.

-Chris

If you're interested in doing this, I'd suggest hacking up the backend to
not run register allocation, and represent all your "physical" registers
are virtual registers. This gives you an unlimited number.

Yes it would be ideal to use all virtual registers, but a glance at the
code seemed to indicate the the use of physical registers, spilling, etc.
was pretty ingrained in all the register allocation algorithms, so it
seemed like it would be difficult to extract. I also still need to
minimize the number of registers and minimize copies as if it were
generating code for more restrictive hardware.

Ideally I'd like something like the linear register allocator but that
never spilled or assigned physical registers, along with other goodies
like coalescing and phi elimination.

On the other hand, just increasing the allowable physical registers would
immediately solve most of my problems.

Andrew

Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree.

-Chris

hi andrew,

Yes, I will create a patch for my tree to increase FirstVirtualRegister. Would this be a good change to include in 2.9?

We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as “invalid register” it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. treat as erroneous) the 0th element of anything keyed off FirstVirtualRegister.

I think it makes the most sense to discuss that when you're interested in merging the dependent work onto mainline. Dales's idea of using positive/negative numbers makes sense to me.

-Chris

Fixed in r123137.

I decided to move the virtual register numbers because there is so much code already using physical register numbers as direct indices.

My first attempt was to let the virtuals run from -1 downwards, but it turns out that we have code in isel depending on createVirtualRegister() returning increasing numbers. DenseMap<unsigned> also complained because it uses -1u and -2u as sentinels.

So I moved the virtual register range to 2^31 growing upwards.

The range from 2^30 to 2^31 is reserved for representing stack slots.

Physical registers get 1 .. 2^30-1.

/jakob

Note that this allows the index translation in an IndexedMap to be optimized away completely in 32-bit builds.

MachineRegisterInfo::setRegClass(unsigned Reg, const TargetRegisterClass *RC) {
const TargetRegisterClass *OldRC = VRegInfo[Reg].first;

Becomes:

movl 12(%ebp), %esi
movl 8(%ebp), %eax
movl (%eax), %ecx
movl (%ecx,%esi,8), %edx

The high bit on the virtual register number falls off in the address computation.

We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as “invalid register” it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. treat as erroneous) the 0th element of anything keyed off FirstVirtualRegister.

Thanks Jakob. This is a microoptimization, but those subtractions were really kludgy-looking.

After writing the above it occurred to me that negative numbers would run afoul of the widespread practice of declaring registers “unsigned”, so this is probably the best way.