[LLVMdev] Parallel Loop Metadata

[Andrew Trick]

On Feb 8, 2013, at 12:28 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote:

> On 02/08/2013 08:20 PM, Tobias Grosser wrote:
>> That sounds elegant and seems to solve the correctness problems.
> 
> There is no big difference here except that the memory instructions
> would not need the metadata.
> 
> I do not think the abundance of metadata is really the main problem, but
> what to do with passes that do not know about parallel loops. How to minimize the changes needed to make the most relevant passes retain the information,
> and more importantly, how to avoid code breakage if they are unaware of
> its meaning.
> 
> Also, I tried something like this when I tried to find a nice way to couple
> the memory and the loop metadata. It seems not possible to directly refer to
> an Instruction from MDNode, or is it? I got crashes when serializing the
> bitcode with MDNodes pointing to Instructions and thought that it's not meant
> to work that way around.

I think you can refer to the memory address values from within your function-local metadata.

> Thus, I created the loop identifier metadata "anchor" to which the both
> metadata types refer.
> Even if it was possible, retaining that information across inlining etc. means
> one has to update those Instruction references in the metadata to the new
> matching ones in the inlined location, etc. The maintenance burden of the data
> in several passes, which I thought was the actual concern of Nadav, gets AFAIU
> even harder. E.g., if you remove memory instructions (e.g. DCE) you get
> dangling pointers in the metadata or a null there which renders the parallel info invalid (and might even cause crashes?), which doesn't happen in the
> current state of the patch.

How is this not a problem for !tbaa?

-Andy

> All in all, if the number of metadata is what pains the most, this
> is an improvement. Otherwise, I see it more fragile, and it's also uncertain if
> it's possible to implement it.
> 
> IMHO, the best alternative presented so far is to have both metadata types
> and potentially exploit the mem.parallel_loop_access MD even if there were
> non-annotated instructions in the loop to *help* the dependency analysis.
> isParallel() would stay as is now in the patch, it can be used as a short cut
> check for a loop of which accesses all have the metadata (to skip the whole
> dependency checking).
> 
> -- 
> --Pekka
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev