[llvm-commits] dependence analysis (of multi dimensional arrays)

Preston Briggs preston.briggs at gmail.com
Tue Sep 25 11:21:40 PDT 2012


Hi David,

> A general comment: Obviously there's two stages:
> 1.       extracting "independence" information implicit in C like
> languages, eg, that an expression is actually a well-behaved
> multidimensional index

Right, though we call it dependence info, since there's often lots of
useful info related to existing dependences. That is, there's more to
the problem that simply proving memory references are independent. I
think we want to build a dependence graph, with instructions for
vertices and dependences for edges. Given the a dependence graph, we
can explore it for opportunities to perform all sorts of interesting
loop xforms.

> 2.       figuring out what further, possibly platform specific,
> optimizations to do once you've got an "independent" representation

Yes indeed. The things I care most about (parallelization,
vectorization, memory hierarchy improvements) are all big projects and
are all platform specific. The dependence analysis and dependence
graph are the foundations. We'll get there.

> Naturally there's a lot of interest in dealing with existing+new codes
> written in C-type languages, but there's also compiling from other languages
> where the semantics already assures many of these properties. It would be
> helpful if there was a semi-stable LLVM-IR+metadata representation that
> systems for those languages could output directly. (I'm thinking of things
> like being able to state directly that loop interchange doesn't affect the
> semantics, as inference of this fact may well fail in some moderately
> complex cases, particularly if the "high-level" compiler does aggressive
> "array re-use".)

I agree. I don't think we'll ever be able to find all the parallelism
(say) we want by analysis alone; we need some scheme (e.g., pragmas)
for programmers to make big promises and communicate their intent to
the optimizer. Similarly, if we're compiling some language with
parallel operations, we hate to throw away information; we'd prefer
that there be a way for the front end to express everything it knows
so it can be exploited during optimization.

Preston



More information about the llvm-commits mailing list