On 8/4/2022 3:49 AM, Richard Sandiford via Gcc-patches wrote:
TBH I'm surprised we still run init_regs for LRA. I thought there was
a plan to stop doing that, but perhaps I misremember.
Sorry I am not sure about the status of LRA... because the xtensa port is still
using reload.
Ah, hadn't realised that. If you have time to work on it, it would be
really good to move over to LRA. There are plans to remove old reload.
Definitely worth investigating. With the cc0 removal done I think the
last blocker for removing the old reload pass is gone. We just need to
get the remaining targets converted to LRA.
It might be that old reload *does* treat a pseudo clobber as a conflict.
I can't remember now. If so, then zeroing the register wouldn't be
too bad (for old reload only).
No idea anymore either. I'd be a bit surprised since IIRC the main
purpose was to tell the old uninit warning code that the entire object
was set by the subsequent libcall sequence. But all that code is long-gone.
Which I think raises a question. Do we even need those CLOBBERSs anymore?
As conclusion, trying to tweak the common code side may have been a bit
premature.
I'll consider if I can deal with those issues on the side of the
target-specific code.
It's likely to be at least partly a target-independent issue, so tweaking
the common code makes sense in principle.
Does adding !HARD_REGISTER_P (x) to:
/* Show the output dies here. This is necessary for SUBREGs
of pseudos since we cannot track their lifetimes correctly;
hard regs shouldn't appear here except as return values. */
if (!reload_completed && !reload_in_progress
&& REG_P (x) && !reg_overlap_mentioned_p (x, y))
emit_clobber (x);
in emit_move_complex_parts help? If so, I think we should do at
least that much.
If we can't remove the CLOBBERs entirely, then this sounds like a good
thing, even if it doesn't help this specific case.
jeff
