On Thu, Jun 11, 2026 at 9:22 PM Jeffrey Law <[email protected]> wrote: > > > > On 6/11/2026 6:33 PM, Andrew Pinski wrote: > > I am not comfortable with the heuristics used here for sink. This is > > why I have not been heavily reviewing that part of the patch yet. > > There has to be a better way of handling this. Maybe the better > > heuristics is just handling this for the last sink rather than early > > sink. There has to have some better way of handling the heuristics > > rather than walking backwards. > The interaction with vectorization is a problem. We've seen that with > multiple transformations. I don't mind asking to explore some more ideas. > > So are you suggesting deferring to post-vectorization and dropping the > heuristics that currently are meant avoid spoiling vectorization. That > seems like a reasonable space to ask Kyrill to explore.
That is partly what patch 3 is designed to do. There is only extra thing to do is check is fold_before_rtl_expansion_p () as an or to `bb_loop_depth (bb) == 0`. I was going to test that out once I pushed the patch 1 and 3 (and my dependent patch here which I am finishing up right now based on Richard's review). I was going to do that yesterday but some personal stuff happened. Even the simplified version for sink I was going to do; that is change patch 2 to remove the heurstic has a similar one to patch 3 with my above addition of fold_before_rtl_expansion_p check Though sink runs right before the last phiopt so it might be the case we only need either phiopt or sink in general here. Plus with the addition of creating a new forwarder block (that is apporved just not pushed because I am still proving to myself that the order of bb processing will always be correct); I am thinking we don't need the sink part in the end. > > > > > > I thought there is a way to tell if ssa name is based on an induction > > variable or not. Which is way cheaper than what is done in this patch. > I thought we had this as well, but I can't find it anymore. We used it > in various places to avoid creating overlapping lifetimes in various > scenarios. > > Jeff
