This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
(Zdenek, I CC'ed you because I need some clarification regarding your loop-structures-preserving project; please see below)
I'd like to provide an update on the ddg-exporting project and request some more comments. Ian, thanks for your feedback and for catching redundant code.
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.
-- bb1 -- loop: smth1; if (cond1) jump out; -- bb2 -- smth2; if (..) jump loop; -- bb3 -- smth3; jump loop; -- out:
-- bb1 -- loop: smth1; if (cond1) jump out; -- bb2 -- loop2: smth2; if (...) jump loop; -- bb3 -- smth3; smth1; if (!cond1) jump loop2;
In the latter sequence, flow_loops_find would find two loops: bb1-bb2 and bb2-bb3. The other obvious source of changing of number of loops would be RTL loop unswitching. There was also an example of order of loops changing after the VRP pass.
Zdenek, could you please clarify whether and how your LoopPreserving project is going to influence the mentioned problems? Are you interested in that VRP example? By the way, I'd like you to remind you that you mentioned before that RTL loop unswitching might be removed from GCC.
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, 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?
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?
Thanks -- Alexander Monakov
Attachment:
export-ddg.patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |