"Robin Dapp" <[email protected]> writes:
>> Hmm, ok. In a way that does feel very like an earlyclobber as well.
>> Perhaps we could say that an earlyclobber on an input is allowed and
>> introduces a conflict with other input operands, but not with the output
>> operands. (A conflict with an output operand should involve an
>> earlyclobber there, in the usual way.) Of course, the C++ condition
>> should still prevent matching (inner) registers, since it seems too much
>> to expect the RA to introduce temporaries.
>>
>> Isn't there a risk that these two requirements (widening/narrowing and
>> non-overlapping inputs) will end up being combined in a single instruction
>> in future, either for RVV or for some other architecture? Defining the
>> restriction in terms of a single other operand wouldn't scale to a
>> three-way restriction, but using earlyclobbers would.
>
> I was thinking of "scaling" dependent filters right away,
> i.e. allowing a list of dependent opnos and passing the current
> operands[] to the backend. I wouldn't dare though :)
I suppose there's an argument that that kind of restriction might be
more natural at the instruction level. That would also avoid having
to introduce an arguably false asymmetry between the input operands of
a scatter (one of them wouldn't have to become dependent on the other).[*]
For example, perhaps there could be a special well-known attribute name --
like "enabled" is -- that enumerates types of interdependency between
operand allocations. There could then be a target hook to say whether a
given group of registers matches the restrictions for a given attribute
value. Perhaps there could also be a wildcard register value to mean
"any register", for registers that haven't been allocated yet.
Just something I made up though, haven't thought it through.
It sounds quite computatioally expensive. Probably prohibitively so
if it was widely used. But it would be general.
> Initially, before starting the implementation, my assumption was that
> adjusting or adding early-clobber semantics would likely not be well
> received and that's why I went the fully-generic route. If new
> earlyclobbers kinds are acceptable, maybe that would be a less
> invasive way?
Let's see what others think. The trade-offs seem clearer to me now.
Richard
[*] Earlyclobbered inputs would also be asymmetric if an earlyclober
on one input could conflict with any other input. But I suppose
we could say that all the interdependent inputs should have
earlyclobbers, which would be both more regular and more flexible
than a single earlyclobber.
