Register constraints for implicit register usage

I am working on a machine with a special register class which here I will call Xrc containing registers X0…Xk.

Some instructions implicitly reference X0. I am modeling this with a pseudo instruction that makes that reference explicit and created a register class X0rc which just contains X0. This seems to work fine and SelectionDAG introduces copies between the two register classes where I would expect them.

The problem I face is that MachineCSE::PerformTrivialCopyPropagation eliminates these copies and effectively changes the register class for the output register of unconstrained instructions to be X0rc. This is done so aggressively that I end up with multiple overlapping live ranges and so values are constantly being spilled and reloaded. Also, it creates situations where multiple operands of an instruction are bound to this class and so register allocation fails.

What is the preferred way to handle this kind of situation?

Thanks

david

Hi David,

I am not sure I understand what you’re trying to achieve.

If you want to model implicit references, you should be able to do that directly by adding implicit x0 references on the related instructions.
You can take a look at how X86 treats EFLAGS for instance.

Cheers,
-Quentin

I was about to say that TargetRegisterInfo::shouldCoalesce can be overridden by the target to prevent coalescing. But it looks like MachineCSE is doing coalescing/propagation without considering that target hook.

Maybe there should be a similar interface (unless shouldCoalesce can be used) to allow a target to prevent coalescing in certain circumstances also in MachineCSE.

It would of course be nice if the register allocator could undo the contrain+coalescing, i.e. splitting the intervals, and then also relax the register classes if possible. Possibly avoiding spill. No idea if that already is attempted or even feasible.

/Björn

Hi again.

One solution could be to do something like this:

// Let the pseudo define X0 but use the larger regclass.

let Defs = [X0] in {

def MyPseudo: SomePseudoInstr<

(outs …), (ins Xrc:$src, …),

…>;

And then when expanding the pseudo, late, typically after register allocation, you might need to introduce a copy from the src register picked by regalloc to X0 before the actual instruction.

/Björn

I was about to say that TargetRegisterInfo::shouldCoalesce can be overridden by the target to prevent coalescing. But it looks like MachineCSE is doing coalescing/propagation without considering that target hook.
Maybe there should be a similar interface (unless shouldCoalesce can be used) to allow a target to prevent coalescing in certain circumstances also in MachineCSE.

It would of course be nice if the register allocator could undo the contrain+coalescing, i.e. splitting the intervals, and then also relax the register classes if possible. Possibly avoiding spill.

That’s exactly what the greed allocator does :).