[PATCH] split, i386, v5: Fix up df uses in i386 splitters [PR99104]

Richard Sandiford richard.sandiford@arm.com
Thu Feb 18 18:29:06 GMT 2021


Jakub Jelinek <jakub@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


More information about the Gcc-patches mailing list