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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]