Hello, > Testing on tree-vectorizer testsuite and some of the GCC source files > showed that frequent source of apparent loss of exported information > were passes that performed basic block reordering or jump threading. > The verifier asserted that number of loops was constant and the order > they are visited by FOR_EACH_LOOP remained the same throughout the > compilation.
you definitely cannot rely on that, the number and order of loops may change due to many different optimizations (for example those you mention, but also others). > Zdenek, could you please clarify whether and how your LoopPreserving > project is going to influence the mentioned problems? Once the patches for the project are merged, the information about loops will be preserved across most of the gimple optimizations; i.e., the loops may still be removed or their order may be changed by different optimizations, but any info attached to "struct loop" corresponding to any given loop will survive (some amount of work may still be needed to keep it correct through some transformations, but in particular for ddg this should not be an issue, as it should stay conservatively correct after almost all optimizations) However, I do not preserve loops on RTL, in particular during tree->rtl expansion; this would need some more work. > That said, I do not see the mentioned concerns as serious problems, > because the verifier can be made more permissive, and one can search > exported data references in all loops. Even if order and count of > loop changes, if we are able to find data dependency relation for two > given MEMs later, it will still make sense, with this notable > exception: if RTL loop unrolling (or reversal) is performed, We do not do loop reversal on RTL. > then the > found ddr will contain incorrect distance (because the increment of > the index changed). Is that correct? What would be the preferred > approach: fixing up the exported data, or discarding the irrelevant > information? Loop optimizations definitely need to know about ddg; it should be fairly easy to keep it up-to-date (invalidating the affected part is also a possibility, however the loops we unroll are most likely exactly the loops for that we later need a better ddg in scheduling, so this would be a bit counterproductive). > I mentioned before that I would need to take care of basic block > duplication on tree level, but I have seen no example of that > happening after iv-opts so far. Does anyone know offhand whether it > is possible? Some code duplication may happen in jump threading, performed in dom and vrp, both are run also after ivopts; they probably do not have that many opportunities to do so at that time, but you cannot rely on that. Zdenek
