[LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer

[Pekka Jääskeläinen]

Hi Tobias,

On 01/29/2013 10:51 AM, Tobias Grosser wrote:
> Is the meta data now still valid or how do we ensure the invalid meta data is
> removed?

It seems it's not valid anymore. Good catch. I was requesting for these
transformation cases earlier. Probably there are more not thought of yet.

> I have the feeling it may be necessary to link the loop as well as the accesses
> for which we can ignore dependences together and mark the whole construct as
> "this set of memory accesses does not have dependences within the mentioned
> loop". Like this, the introduction of additional memory accesses which may very
> well introduce dependences that we need to preserve, can be easily detected. The
> parallelism check would now be: "In case the llvm.loop.ignore_assumed_deps
> meta-data is found in a loop header _and_ all memory accesses in the loop are
> referenced by this meta-data, the loop is parallel. If there is a memory
> access that does not reference the ignore_assumed_deps meta-data, we
> can not assume anything about the loop.

Sounds reasonable, as it's too intrusive to start making all the passes
parallel loop-aware.

Also, I was thinking how to *retain* this data during unrolling. At least
in-order targets benefit from the information in their alias analysis to
produce more instruction scheduling freedom while scheduling code from the
unrolled parallel iterations. Also the BBVectorizer should benefit from this.

Annotating the memory operations in the iteration should cover this use case
also if the metadata also includes the iteration id. Then at the unroll time,
the metadata can be replicated and the id incremented. An alias analyzer
(something similar we have in pocl for unrolled/chained work items) then can
check for this metadata and return NO_ALIAS for accesses from different iterations.

Going even further, maybe this same (or similar) format can be used to
retain restricted pointer (noalias) information across inlining. Lack of this
has been a bit of a nuisance for us in TCE.

In the restricted ptr case one wants to mark pointers with some kind of
context marker (e.g. a function name + pointer identification) which
communicates that the accesses through that pointer do not alias with
other pointers in the same function context.

The mem accesses in the parallel loop iteration could have a metadata
"llvm.mem.parallel_loop_iter 0 0" or similar where the first id is a
loop id, the latter the iteration id. Restricted pointer mem accesses
could use metadata "llvm.mem.restrict my_function my_pointer". A parallel
loop alias analyzer can use the parallel_loop_iter metadata (if loop id
equals but iteration id doesn't, return NO_ALIAS) and a restrict pointer
AA use the latter (if both of the queried pointers have it and it differs
for the pointer part only, return NO_ALIAS).

-- 
--Pekka