[llvm-commits] dependence analysis

[Chandler Carruth]

On Fri, Jul 27, 2012 at 10:39 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Fri, 27 Jul 2012 17:31:44 -0700
> Preston Briggs <preston.briggs at gmail.com> wrote:
>
> > On Fri, Jul 27, 2012 at 5:06 PM, Evan Cheng <evan.cheng at apple.com>
> > wrote:
> >
> > >> I wrote a test driver that makes dependence queries along with 100+
> > >> tests that exercise most everything.
> > >> Again, I'm not sure how to organize all this into a format LLVM
> > >> can use.
> > >
> > > Can they be made into unit tests? The first step is to send the 2
> > > files for review. It would be worthwhile to include a few of these
> > > tests so folks can get a better idea what they look like and how
> > > the analysis can be used. But I don't expect anyone will look
> > > through all of them right away.
> >
> > Looking the testing infrastructure document...
> > I was thinking in terms of regression tests.
> > So far, I've organized the tests into 14 C files,
> > translated the C files into 14 .ll files,
> > and created result files for each of the 14.
> >
> > Seems odd to throw away the C source and keep only the .ll
> > How will people ever understand what's going on?
>
> You could include the C loop in a comment block in the .ll file.


While this is helpful, I find that the most useful thing to make useful
'.ll' tests is to really heavily hand modify them.

Fundamentally, the IR generated by a proper C frontend has a lot of
details, noise, and clutter that simply aren't needed when you are testing
a single specific feature.

My typical pattern is this:

1) Write C code and run it through a frontend to get a good
"representative" IR formation for the loop or structure under test.
2) Hand minimize the IR down to the bare essentials for the construct I'm
testing. This usually involves removing attributes, alignment, metadata,
etc etc.
3) Flesh out this minimal IR with more human-friendly names, often
leveraging the domain terminology (such as the common lexicon used for
referring to elements of naturally structured loops).
4) Add comments about the structural entities being tested. I find that for
loops ASCII art actually is brilliant in the comments.

The comments you add in #4 also then form excellent context for adding
comment-wrapped FileCheck assertions on what the expected results are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120728/49622f94/attachment.html>