Jakub Jelinek <ja...@redhat.com> writes:
> On Wed, Feb 17, 2021 at 10:30:06AM +0000, Richard Sandiford wrote:
>> Hmm. I think that just means that the optimisation performed by
>> the copy constructor isn't valid in practice (even if it should be
>> in principle). Guess this is the curse of manipulating data structures
>> directly rather than through well-defined interfaces :-)
>>
>> TBH, since the obvious thing didn't work, I think we should keep it
>> simple and take the hit of the full copy. It seems less error-prone
>> and I'd be surprised if the overhead was noticeable in practice.
>> It also means that if we do manage to optimise the copy in future,
>> all callers would automatically benefit.
>>
>> I.e. my preference would be to go for your original patch without
>> the recog.[hc] bits.
>
> It is more than 1KB there and back each time we call one of those
> splitter conditions.
> When we know only the recog_data.{operand,insn} part is needed...
> Only copying that would be 240B there, back + clear of 8 bytes.
Yeah, agree that copying 1KB isn't great, but I think we should keep any
optimisations of the copy in recog.[hc]. So IMO it would be better &
safer to go with a plain copy for now and leave optimising it as a nice
future improvement. (Or even better, we could try to remove the
reliance on a single global.)
Thanks,
Richard
> Anyway, don't feel strongly about that.
>
> Jakub
