https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117467
--- Comment #16 from Jeffrey A. Law <law at gcc dot gnu.org> --- OK. Funny I'd just been looking at this problem in a different context. When an RTX is encountered when handling uses that the code does not know how to handle it will, in effect, continue normal iteration through the sub-rtxs marking any REG seen as completely live. Seems sensible. What goes wrong (and what I was looking at earlier this week) is that processing will dive into the destination. We certainly need to look at the destination; consider it could be a MEM and there may be REGs in the address. But it just blindly goes through the entire RTL object. So even a simple LHS such as (set (reg) ...) will make the reg as *live*. It's safe, but highly suboptimal. I'd planned to tackle this in gcc-16 in an attempt to clean up the control flow in the use handling. But I think I need to accelerate at least an investigation of cleaning up the use handling ot avoid this problem. To answer another question from this BZ. No, ext-dce doesn't really duplicate the functionality found elsewhere such as combine, ree, cse. Combine comes the closest as combine does some nonzero & sign bit tracking. But it doesn't do a livetime analysis on a global basis and use the results to simplify RTXs. REE is concerned with finding multiple extension rtxs and eliminating one, similarly for CSE.
