On 11/10/23 03:39, Richard Sandiford wrote:
Lehua Ding <lehua.d...@rivai.ai> writes:
On 2023/11/10 18:16, Richard Sandiford wrote:
Lehua Ding <lehua.d...@rivai.ai> writes:
Hi Richard,
On 2023/11/8 17:40, Richard Sandiford wrote:
Tracking subreg liveness will sometimes expose dead code that
wasn't obvious without it. PR89606 has an example of this.
There the dead code was introduced by init-regs, and there's a
debate about (a) whether init-regs should still be run and (b) if it
should still be run, whether it should use subreg liveness tracking too.
But I think such dead code is possible even without init-regs.
So for the purpose of this series, I think the init-regs behaviour
in that PR creates a helpful example.
Yes, I think the init-regs should be enhanced to reduce unnecessary
initialization. My previous internal patchs did this in a separate
patch. Maybe I should split the live_subreg problem out of the second
patch and not couple it with these patches. That way it can be reviewed
separately.
But my point was that this kind of dead code is possible even without
init-regs. So I think we should have something that removes the dead
code. And we can try it on that PR (without changing init-regs).
Got it, so we should add a fast remove dead code job after init-regs pass.
I'm just not sure how fast it would be, given that it needs the subreg
liveness info. Could it be done during RA itself, during one of the existing
instruction walks? E.g. if IRA sees a dead instruction, it could remove it
rather than recording conflict information for it.
Yea, it's a real concern. I haven't done the analysis yet, but I have a
sense that Joern's ext-dce work which Jivan and I are working on
(which does sub-object liveness tracking) is having a compile-time
impact as well.
Jeff
