Skip to content

Adding Fortran call graph collector#115

Open
gomfol12 wants to merge 130 commits intotudasc:develfrom
gomfol12:fortran_collector
Open

Adding Fortran call graph collector#115
gomfol12 wants to merge 130 commits intotudasc:develfrom
gomfol12:fortran_collector

Conversation

@gomfol12
Copy link
Contributor

@gomfol12 gomfol12 commented Feb 5, 2026

This adds a call graph collector for Fortran. The collector is implemented as a flang plugin and generates a call graph from source-level. See the tests for a list of language features this plugin covers.

This pull request is quite large, but it is not really possible splitting it in multiply requests without pushing broken code. The tests could be separate into a different pull request, but they are tightly coupled with the collector and would fail without it, so I think keeping it in one pull request makes sense.

What this adds:

  • new directory cgfcollector that includes flang plugin, tests, tools, etc.
  • flang plugin that generates call graph in metacg format.
  • two wrapper script cgfcollector_wrapper.sh and cgfcollector_comp_wrapper.sh that simplify running the plugin.
  • cgCompare tool: for comparing two call graphs (can be replaced with cgdiff)
  • another test runner

How to run: see cgfcollector/README.md

The commit history is a mess, and I don't know how strongly you value a clean git history and if I should clean this up.

Copy link
Member

@pearzt pearzt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for all the work, the structure looks really good. I have some initial comments, but I will try to do a more in-depth review soon.

Copy link
Member

@jplehr jplehr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this.

I did an initial brief pass, please go through the comments and address them.

One more question: Does this PR as-is already run CI pipelines? If not, please add it to the CI pipelines as appropriate.

using namespace Fortran::semantics;
using namespace Fortran::parser;
using namespace metacg;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably live inside the metacg namespace?
If not, it should likely live in its own namespace.

What are others' opinions here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't really have a common scheme for namespaces. Headers that are used for more than one tool (e.g., public-facing headers) should use metacg::*, I guess, but that's not the case here.

Until we agree on a policy, I would leave it to @gomfol12 whether to use a namespace. If we want to use a namespace, I'd suggest metacg:: or metacg::cgfcollector.

dot::DotGenerator dotGen(cg);
dotGen.generate();

std::unique_ptr<llvm::raw_pwrite_stream> dotfile = ::createOutputFile(getInstance(), getCurrentFile(), "dot");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be problematic in parallel CI runs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should separate the concerns between call graph generation and visualization. cgfcollector produces the call graph. If the user want a visualization, they can use your dot export tool for this (which is a nice addition, btw).


std::string cgString = dumpCG();

std::unique_ptr<llvm::raw_pwrite_stream> file = ::createOutputFile(getInstance(), getCurrentFile(), "");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be problematic in parallel CI runs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be named visual?

Is this limited to the Fortran support? I would assume this can be factored out into another PR and put in as a general tool.
Other people's thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this is something that should extracted into a separate PR.

message(STATUS "Using MLIR version: ${MLIR_VERSION}")

function(add_flang target)
target_compile_definitions(${target} PRIVATE FLANG_LITTLE_ENDIAN)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this always the case? I tend to believe that this may be platform specific?
If so, let's put a TODO / XXX / Comment here.

@pearzt
Copy link
Member

pearzt commented Feb 17, 2026

Please rebase this onto the most current devel.

generateCG(getParsing().parseTree(), getCurrentFile());

std::string cgString = dumpCG();
std::unique_ptr<llvm::raw_pwrite_stream> file = ::createOutputFile(getInstance(), getCurrentFile(), "json");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the MCGWriter infrastructure for file output. For an example how to use this, have a look at tools/cgconvert/CGConvert.cpp.

dot::DotGenerator dotGen(cg);
dotGen.generate();

std::unique_ptr<llvm::raw_pwrite_stream> dotfile = ::createOutputFile(getInstance(), getCurrentFile(), "dot");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should separate the concerns between call graph generation and visualization. cgfcollector produces the call graph. If the user want a visualization, they can use your dot export tool for this (which is a nice addition, btw).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments