backend: (riscv) add tied operands/results to register allocation

[nazavode]

This PR adds the concept of tied operands found in LLVM to be able to model 2-address instructions, a.k.a. when an operand register is both read and written in-place by an instruction. Both the operand and the result must be represented in their own SSA values, but the regalloc must allocate both on the same register to be able to generate correct code.

Keeping as draft for feedback, things that I would like to change:

• I don't like the APIs, it could be nice to have our own TiedConstraint instead of a generic ConstraintVar("T")
• The code that collects all operands/results definitions that share the same ConstraintVar is a mess, to be cleaned up.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.89%. Comparing base (75b78ec) to head (c43afd9).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2887      +/-   ##
==========================================
+ Coverage   89.85%   89.89%   +0.03%     
==========================================
  Files         399      402       +3     
  Lines       50171    50459     +288     
  Branches     7755     7785      +30     
==========================================
+ Hits        45083    45360     +277     
- Misses       3860     3865       +5     
- Partials     1228     1234       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[superlopuh]

I was thinking you were going to do something a bit more like this:

Suggested change

	class TestOp4(Generic[RD1InvT, RD2InvT, RS1InvT, RS2InvT], RISCVInstruction, ABC):
	rd1: OpResult = result_def(RD1InvT)
	rd2: OpResult = result_def(RD2InvT)
	rs1: Operand = operand_def(RS1InvT)
	rs2: Operand = operand_def(RS2InvT)
	def assembly_line_args(self) -> tuple[AssemblyInstructionArg, ...]:
	return self.rd1, self.rd2, self.rs1, self.rs2
	class TestOp4(Generic[RdRsInvT, RD2InvT, RS2InvT], RISCVInstruction, ABC):
	SameIntRegisterType: TypeAlias = Annotated[RdRsInvT, ConstraintVar("RdRs")]
	rd1: OpResult = result_def(SameIntRegisterType)
	rd2: OpResult = result_def(RD2InvT)
	rs1: Operand = operand_def(SameIntRegisterType)
	rs2: Operand = operand_def(RS2InvT)
	def assembly_line_args(self) -> tuple[AssemblyInstructionArg, ...]:
	return self.rd1, self.rd2, self.rs1, self.rs2

So embedding in IRDL the fact that it's the same variable, as opposed to constraining the generic parameter itself.

[nazavode]

Much nicer! In this case tho I'm instantiating the generic class with different tie constraints for testing reasons, your suggestion would be 100% error proof when defining real world operations.

[superlopuh]

It might be interesting to split this in two, to first add the constraint logic and use it in our current loop allocation code (to constrain that the iter args, block args, and results are in the same registers) and then to use it for operations with same register constraints like in this PR

[nazavode]

It might be interesting to split this in two, to first add the constraint logic and use it in our current loop allocation code (to constrain that the iter args, block args, and results are in the same registers) and then to use it for operations with same register constraints like in this PR

This PR adds just the bare logic and a a handful of fictional ops just for testing purposes. I think trying to apply it to loops allocation first would be a strong stress test before having the whole thing merged. Trying it out on a stacked branch!

[superlopuh]

What's the plan for this? Did we merge the equivalent logic or does this branch go further than what we came up with in Zurich?

[nazavode]

What's the plan for this? Did we merge the equivalent logic or does this branch go further than what we came up with in Zurich?

I think that all we need has been merged already, happy to close this!

[superlopuh]

Fantastico