[LLVMdev] SIV tests in LoopDependence Analysis, Sanjoy's patch

Preston Briggs preston.briggs at gmail.com
Mon May 14 15:18:12 PDT 2012


On Mon, May 14, 2012 at 2:14 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>> > One thing that I would like to mention is that 'use' here should
>> > also include user feedback. This means being able to pass
>> > information back to the frontends about which loops are being
>> > effectively analyzed, and for loops that are not, why not.
>>
>> Absolutely. I've been thinking in terms of passing info back to the
>> programmer (see
>> https://sites.google.com/site/parallelizationforllvm/feedback). It's a
>> very interesting problem and one where I think there are real research
>> possibilities.
>
> Do you think that we should do this by adding metadata, or should we
> establish some kind of separate feedback channel? Metadata would make
> it more useful for writing regression tests (perhaps), but a separate
> feedback channel might be more useful for the front ends. Maybe we
> should have a separate feedback channel that, lacking any other
> consumer, writes out metadata?

I don't know what's best.  Probably different uses merit different mechanisms.

At Tera, we did regression tests by using command-line flags to
provoke particular passes to dump so-called signature information to
stderr. For example, -trace:PAR_SIG would cause the parallelizer to
dump out a condensed account of what it did for each loop nest.
Similarly, -trace:LS_SIG would cause the loop scheduler (i.e.,
software pipeliner) to dump a summary for each inner loop. As part of
each night's tests, we'd compare the signatures against standards and
report differences.

Later, we developed a tool called "Canal" that took essentially the
same information and used it to produce an annotated listing, where
each loop nest was marked to indicate what the parallelizer had done
to it, each inner loop was decorated with info about what happened
during software pipelining, etc. Still later, we built a GUI-tool to
report the same info in a little more convenient fashion.

The most useful information came from the various transformation
passes. For example, the parallelizer reporting that certain
loop-carried dependences prevented parallelization; the software
pipeliner would report on the length of inner loops (in ticks) , the
balance between memory references and floating-point ops, and so
forth.

Preston



More information about the llvm-dev mailing list