On Thu, Dec 01, 2016 at 11:48:03PM +0100, Bernd Schmidt wrote:
> On 12/01/2016 11:43 PM, Jakub Jelinek wrote:
> >
> >so we'd need to slow shallow_copy_rtx down by adding switch (code)
> >in there or something similar.
>
> Is there reason to assume it's time-critical? IMO eliminating the potential
> for error by not having callers need to do this outweighs that concern.
Well, it isn't an error not to clear it, just missed optimization if some caller
cares, and most of the shallow_copy_rtx users really don't care, e.g.
config/i386/i386.md and config/i386/i386.c callers. cfgexpand.c doesn't
either, at that point the used bit isn't set, the calls in cselib.c don't care
either. In emit-rtl.c one place explicitly sets used flag afterwards, another
clears it (that one could be removed if the logic is moved down). The rs6000.c
use indeed could get rid of the explicit used bit clearing. Most of the
other shallow_copy_rtx callers in the middle-end just don't care.
I think it is really just simplify_replace_fn_rtx where (at least in the
rs6000 case) it is useful to clear it, similar trick is not used in many
places after initial unsharing during expansion before which the bit should
be clear on everything shareable, I saw it in ifcvt.c (set_used_flags
+ some copying + unshare_*_chain afterwards).
After expansion when everything is unshared, gradually the used bits are no
longer relevant, they are set on stuff that has been originally unshared and
clear on newly added rtxes. Then the reload/postreload
unshare_all_rtx_again clears it and unshares the shared stuff.
So it is really just about spots that do the trick of set_used_flags,
call some functions where clearing of used bit on new stuff is important,
and finally call copy_rtx_if_shared.
Jakub
