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.
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.
--
Best,
Lehua (RiVAI)
lehua.d...@rivai.ai
