https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> --- So given the SLP graph we should have scalar stmts recorded for each entry and for the leafs. We mark the leafs and then walk the SSA use-def chains from the entries, marking defs recursively until we hit the marked leafs (we effectively built the single-lane SLP graph of relevant stmts this way). We then process all marked defs, looking for immediate uses that are not marked (those are defs that need to be live code-generated or kept). We then can walk the SLP graph, looking for live marked SLP scalar stmts and mark the SLP node accordingly - those not explicitly represented in the SLP graph cannot be live code-generated anyway. The marking code should be effectively the relevancy marking code or code split from SLP discovery that determines relevant SSA uses. As indicated this should be usable to build a single-lane SLP graph for loops as well. What remains then is a precise way to analyze whether we can code-generate the live lanes where scalar code uses impose scheduling constraints for the vector code generation. The plan for that was to make the scheduling explicit during analysis already, thus record a gsi where the vector code for an SLP node is to be generated - dependence checking can be done after scheduling or before and constrain scheduling. I'm going to start working on this soon.
