On 5/28/26 6:24 PM, Richard Sandiford wrote:
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.
I meant how to improve IRA allocation. When you have early clobber only
in one alternative, how to treat it optimistically (probably no clobber)
or pessimistically (always clobber as it is done in IRA). So for IRA it
is more not a constraint but rather operand predicate.
But the bigger concern for me is about introducing a new constraint
which I consider is more permanent and widely used feature than hooks
and I am not sure it will stay unchanged and be widely used. If we need
to generalize the operand dependency, I think for the constraint it
would be more difficult.
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.
Sorry, Richard, for not to be clear what I meant is that you need to
process constraint strings to find the special earlier clobber. Of
course it could be cached in recog_op_alt as it is done for regular
early clobber but still there will be a loop on alternatives (to avoid
it another cache data could be used). So caching probably would be
analogous what is already done in the proposed patch.
Again, I believe the existing approach is pretty reasonable for me.
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.
