On Wed, 2020-01-22 at 12:02 +0000, Richard Sandiford wrote: > One consequence of r276318 was that cselib now preserves sp-based > values across function calls. This in turn convinced cprop to > replace the clobber in: > > (set (reg PSUEDO) (reg sp)) > ... > (call ...) > ... > (clobber (mem:BLK (reg sp))) > > with: > > (clobber (mem:BLK (reg PSEUDO))) > > But I doubt this could ever be an optimisation, regardless of what the > changed instruction is. Extending the lifetimes of pseudos can lead to > extra spills, whereas sp is available everywhere. > > More generally, I don't think we should replace any fixed hard register > with a pseudo. Replacing them with a constant is still potentially > useful though, since we'll only make the change if the insn pattern > allows it. > > This part 1 of the fix for PR93124. Part 2 contains the testcase. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? > > Richard > > > 2020-01-22 Richard Sandiford <richard.sandif...@arm.com> > > gcc/ > PR rtl-optimization/93124 > * cprop.c (cprop_replace_with_reg_p): New function. > (cprop_insn, do_local_cprop): Use it. In theory there may be cases where replacing a fixed hard register with a pseudo in turn might allow a allocation of the pseudo to a different hard register which *could* have a different cost.
But in a CLOBBER insn, none of that should matter. Would it make sense to only do this on CLOBBERS? I'm not rejecting. Mostly I'm worried about unintended consequences and wondering if we narrow the cases where we're changing behavior that unintended consequences are less likely to pop up. Jeff
