[BDA] join_blocks postDomTree

[Commaster]

How can you be sure that pdNode in https://github.com/cdl-saarland/rv/blob/develop/src/analysis/BranchDependenceAnalysis.cpp#L74-L75 is never nullptr?

short snippet of the issue: https://gist.github.com/Commaster/dd1c370933fc55e83aa371fcd24e327d

Is there a pass I should be performing before analyze (besides the preparatoryPasses)?

I can supply the RV_DEBUG log if needed.

[Simon Moll]

If the post-dominator tree is valid (and all blocks are reachable from the function entry) then all basic blocks have a corresponding node in the postDomTree.

const auto * pdNode = postDomTree.getNode(const_cast<BasicBlock*>(term.getParent()));
const auto * ipdNode = pdNode->getIDom();

They may not have an immediate post-dominator though:

const auto * pdBoundBlock = ipdNode ? ipdNode->getBlock() : nullptr;

I suppose you should validate the postDomTree before going into the VA. If that doesn't help, i'd like to have a look at the RV_DEBUG output.

[Commaster]

postDomTree.verify() returned true.

https://gist.github.com/Commaster/be8247675661627d6b27878999b29336

I tried to track it down and it turns out, that the same branch is BDA'd for the second time. Following the user chain up I came up on lines 7076 and 7139.
7076: %add7.i40.i.i.i has all dependencies shaped, so its own shape is calculated.
But then.
7139: %add7.i40.i.i.i is once again in the queue and this time without a shape (and no shapes on the dependencies either)

I can't quite understand, how this is even possible.

I hope you can provide some pointers on the cause of this confusion.

Thank you!

[Commaster]

I now have also printed vecInfo at each # next and by line 7139 the instruction, as well as the dependencies have a shape. Why does VA ignore it, no idea...

[Simon Moll]

Can you attach the complete module LL file? I'll also need to know the vector mappings for your builtin functions.

[Commaster]

I hope this contains all the info you requested: https://gist.github.com/Commaster/d0cf4746443078aa88d631b29f1b8862

[Simon Moll]

I suspect what you see in your logs are two instances of fadd by the name %add7.i40.i.i.i. Those are probably named apart during serialization and the second one turns into %add7.i40.i.i.i.i (node the 4th i).

Run the following on a RV_DEBUG=on build of RV:

rvTool -i aobench.ll -x llvm.pacxx.read.tid.x=C -k _ZN5pacxx2v213genericKernelIZ4mainE3\$_0EEvT_PPKc -wfv -analyze -w 8 -o /tmp/bla.ll |& grep \%add7.i40.i.i.i | grep Marking

Output:
"""
Marking varying: %add7.i40.i.i.i = fadd float %mul6.i39.i.i.i, %add.i36.i.i.i
Marking varying: %div.i165.i.i = fdiv float -5.000000e-01, %add7.i40.i.i.i
Marking varying: %12 = call float @llvm.fabs.f32(float %add7.i40.i.i.i)
Marking varying: %add7.i40.i.i.i.i = fadd float %mul6.i39.i.i.i.i, %add.i36.i.i.i.i
Marking varying: %div.i.i.i.i = fdiv float %sub10.i.i.i.i, %add7.i40.i.i.i.i
Marking varying: %25 = call float @llvm.fabs.f32(float %add7.i40.i.i.i.i)
"""

[Commaster]

Yes, Both 4i and 3i exist. I'm getting closer to the issue: (note the "from .. " parts)

\# next:   %add7.i40.i.i.i = fadd float %mul6.i39.i.i.i, %add.i36.i.i.i from _ZN5pacxx2v213genericKernelIZ4mainE3$_0EEvT_PPKc.vectorizer.tmp
computed: varying
...
\# next:   %add7.i40.i.i.i = fadd float %mul6.i39.i.i.i, %add.i36.i.i.i from _ZN5pacxx2v213genericKernelIZ4mainE3$_0EEvT_PPKc
	missing op shape   %mul6.i39.i.i.i = fmul float %div.i, -0.000000e+00 from _ZN5pacxx2v213genericKernelIZ4mainE3$_0EEvT_PPKc!
	missing op shape   %add.i36.i.i.i = fadd float %mul2.i.i.i.i, %mul.i32.i.i.i from _ZN5pacxx2v213genericKernelIZ4mainE3$_0EEvT_PPKc!

Somehow instructions from a different function(Region) are getting into the worklist. That's why BDA returns nullref - the instruction belongs to a different BB from a different function, just looks exactly the same.

[Simon Moll]

Ok. That's not an issue with RV then. Can we close this?

[Commaster]

But it is.

https://github.com/cdl-saarland/rv/blob/develop/src/analysis/VectorizationAnalysis.cpp#L242

The pinnedValue-User-Instruction is never verified to be from the same Function.
Setting the condition to (inst && inst->getFunction() == &F) solves the issue.

[Simon Moll]

Good catch! fe4176d confines all users on the worklist to the current region.