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). Thanks, Richard > >> I agree with Richi of course that compile-time is a concern. >> The patch seems to add quite a bit of new data to ira_allocno, >> but perhaps that's OK. ira_object + ira_allocno is already quite big. >> >> However: >> >> @@ -387,8 +398,8 @@ struct ira_allocno >> /* An array of structures describing conflict information and live >> ranges for each object associated with the allocno. There may be >> more than one such object in cases where the allocno represents a >> - multi-word register. */ >> - ira_object_t objects[2]; >> + multi-hardreg pesudo. */ >> + std::vector<ira_object_t> objects; >> /* Registers clobbered by intersected calls. */ >> HARD_REG_SET crossed_calls_clobbered_regs; >> /* Array of usage costs (accumulated and the one updated during >> >> adds an extra level of indirection (and separate extra storage) for >> every allocno, not just multi-hardreg ones. It'd be worth optimising >> the data structures' representation of single-hardreg pseudos even if >> that slows down the multi-hardreg code, since single-hardreg pseudos are >> so much more common. And the different single-hardreg and multi-hardreg >> representations could be hidden behind accessors, to make life easier >> for consumers. (Of course, performance of the accessors is also then >> an issue. :)) > > Okay, I'll try. Thank you so much.
