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.
Anyway, don't feel strongly about that.
Jakub
