https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 15 Jun 2016, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403 > > Jan Hubicka <hubicka at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rguenther at suse dot de > > --- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> --- > > > What I don't see is any reasonable API for invaliding the saved iteration > > data. It appears to be attached to the loop with no way to update it. > > Updating is usually done by hand because it depends on particular loop > transform you make. See unrollin/vectorizing/peeling code and search for > any_upper_bound. > > Here you fuse two loops and I think the reasonable thing is to claim that > original loops no longer exists i.e. remove it and let loop fixup code to > discover the new loop. This is Richard's area, so he may have different > preferences. Obviously the two estimates can be merged, because the loop > iterates at most inner_upper_bound*outer_upper_bound times.. Re-discovering the loop should be done only as a last resort. It does for example lose the fact that you might have specified #pragma ivdep on the outer one. Or the simduid for OMP simd loops. So it's an interesting one at least ;) But I can't see how you really can "merge" the loops via threading as threading doesn't adjust IVs so there will be two loops remaining. I'd have to have a closer look on the testcase (before the fix I guess) but I'm leaving for vacation really soon.
