tudasc/MetaCG

CGCollector does not terminate when applied to OpenFOAM

Opened this issue · 3 comments

sebastiankreutzer commented

I'm trying to run cgcollector on source code from OpenFOAM.
After having tried multiple different source files, it seems that cgcollector does not terminate on any of them (I've tried letting in run for up to three hours).
I am running cgcollector directly without the wrapper script, setting the necessary system includes (and a few other parameters) manually.

The command looks as follows:
tools/cgcollector /opt/OpenFOAM-v2106/src/OpenFOAM/algorithms/indexedOctree/indexedOctree.C -- -DWM_LABEL_SIZE=64 -DWM_DP -I/opt/modules/packages/llvm/11.1.0/lib/clang/11.1.0/include -I/opt/OpenFOAM-v2106/src/OpenFOAM/lnInclude -I/opt/OpenFOAM-v2106/src/OSspecific/POSIX/lnInclude

I observe the following behavior:

  • The analysis seems to start normally
  • In the beginning, there are a lot of messages saying [Warning]: LHS symbol is not of type VarDecl
  • The 'Unresolved before/after the loop" counters increase steadily
  • After a while, the program only outputs [Warning] Unable to determine direct callee. repeatedly

I should note that I've tried out MetaCG on some other test codes with no issues.

I have attached a log file of the full output after running for a few minutes:
cgc_octree.log

sebastiankreutzer commented

My workaround for now is to comment out everything in CGBuilder::handleFunctionPointerInArguments.

jplehr commented

Hi @sebastiankreutzer thank you for the report.

This is unfortunate, and we are aware of the issues in the current implementation. Increasing the runtime limit may resolve the issue, but without guarantee. We saw similar behavior in another C++ code from the SPEC CPU benchmark suite that eventually terminated after 12 hours or so.

We are working on this issue, and hopefully it will be addressed in the not so distant future. ;)

In the meantime, you should certainly apply CGValidate with a Score-P profile to validate the CG, and potentially patch-in missing edges. You can also try out Phasar for its LLVM-based CG generation. Although I don't know whether this is possible in your particular case.

sebastiankreutzer commented

Thanks for the suggestions, I will try out CGValidate. As I understand it, the current issue only concerns the tracking of calls through function pointers. Leaving those out hopefully won't have a dramatic impact on the quality of the CG.

Regarding Phasar: If I'm not mistaken, they rely on merging on all LLVM-IR modules into one. Considering the size of our target application, this might be impractical. I'll keep it in mind in case the current approach does not work out.

  • 👍1