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]

Re: Re[2]: [GSoC: DDG export][RFC] Current status


(Zdenek, I CC'ed you because I need some clarification regarding your
loop-structures-preserving project; please see below)

Hello,

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.

The number of loops may be changed, for example, when

-- bb1 --
loop:
smth1;
if (cond1) jump out;
-- bb2 --
smth2;
if (..) jump loop;
-- bb3 --
smth3;
jump loop;
--
out:

is transformed into

-- 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]