On Tue, 24 Jun 2025, Jan Hubicka wrote: > > > That is why I checked for loc != UNKNOWN_LOCATION. I did not expect > > > UNKNOWN_LOCATION to have discriminators. What they are good for? > > > > I have no idea, this was simply a defensive review where it's no > > longer obvious that inlined_function_outer_scope_p would still work > > in all cases. > > Understood. I am not too familiar with discriminator implementation, > but it seems that afdo is actually quite useful testsuite for profile > info, so I suppose I will learn. > > Before inline stacks were applied correctly, it was kind of useless to > debug other issues. Now the profiles seems much more sane at least when > inlining at instrumentation time matches inlining at profile use time. > > What seems to be common now is profile breakage around loops that has > been fully unrolled or vectorized which is bit undderstandbale thought I > wonder if we can improve here. I think we can fix problem where profile > of loop header stmts is partly or fully lost (which seems to be main > issue now that prevents loop optimization since then loop headers looks > cold). I suppose this can be fixed by making sure the debug statement > is duplicated into the loop variants. > > However I wonder if we can preserve info that after vectorizaiton one > vectorized stmt actualy performs multiple original stmts...
I think the best we can possibly do is to preserve the original scalar control IV via debug stmts. Of course IVOPTs will likely mess that up. Currently the vectorizer invents new control IVs for each loop it generates, I'd like to see it use a single downward counting IV tracking remaining scalar iterations throughout the main vector loop and the prologue/epliogues, that should also simplify code a bit. OTOH it will likely make IVOPTs job a bit harder (since that only considers one loop at a time). OTOH, there'll be N active scalar IV values at each point, so maybe this doesn't help at all without some extra dwarf/consumer support. Richard.
