Vladimir Makarov <[email protected]> writes: > 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.
I think all of the approaches we discussed would be per-alternative. (Robin's contraints, earlyclobber constraints, or the insn attribute/hook combo.) Earlyclobbers are currently per-alternative and I don't think we'd want any extension of them to be less flexible than that. > Also working with constraints (finding it) will be more expensive than > with hooks. Just to check, do you mean that this is an advantage of using the special attribute that I mentioned, plus a target hook? My reason for asking is that, in the context of the paragraphs above and the paragraph below, it sounded like you were saying that working with constraints was a disadvantage of earlyclobbers specifically, whereas the current solution is also based on constraints rather than hooks. Richard > 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.
