On 5/28/26 12:14 PM, Richard Sandiford wrote:
Let's see what others think. The trade-offs seem clearer to me now.
I examined proposed LRA/IRA relative patches. There are many ways to
approach the problem. And the approaches can be characterized by code
change size, how general they are, how they affect compiler time.
And my opinion the proposed solution is adequate, not big code change,
non-expensive, and has potential to be developed into more general solution.
At first glance special earlyclobber looks attractive but code changes
probably will be the same (or even more).
I believe new insn operand constraints should be introduced when there
are a lot of targets using this (once I made a mistake to introduce new
constraints for LRA). It is not the case right now.
Also what semantics should be for a special earlyclobber constraint when
it is used only in one insn alternative. We could constrain it to one
alternative insn definitions or it should be in all alternative.
Also working with constraints (finding it) will be more expensive than
with hooks.
So I prefer the current solution and the most important it is already
implemented.
So I am going to review the LRA/IRA patches and most probably approve it.
The current discussion was quite useful to me. Although discussion of
the solution in advance of implementation start with interested parties
would have been worth to do.
