> > 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. > > There's Alex's series as well waiting on review which fixes profile > information with early-exit (PR117790): > https://inbox.sourceware.org/gcc-patches/adctfxjzqewre...@arm.com/
I know of it and I was replying to the question about the inconsistent profile handling this week too. I do apologize for taking so long - I tought this was already approved, but it got stuck on that special case. Alex, is there something else I should look into? I over-planned last semester but should be more in regular scheduel again. Profile updating patches are really welcome. It is a bit of an independent issue. Alex's profile updating solves "forward" problem: you know profile before vectorization and you need to turn it into a profile after vectorization. Auto-profile is working in a reverse direction. We have sampled executoun counts counts of individual (real or debug) statements after optimization done to the train run. Now we need to produce CFG profile for the feedback build for CFG is not optimized yet. This is kind of fun problem by itself and can be useful to detect situaitons where we forget to update debug statements correctly. Honza > > sam
