Conversation
pearzt
left a comment
There was a problem hiding this comment.
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.
jplehr
left a comment
There was a problem hiding this comment.
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.
cgfcollector/include/edge.h
Outdated
| using namespace Fortran::semantics; | ||
| using namespace Fortran::parser; | ||
| using namespace metacg; | ||
|
|
There was a problem hiding this comment.
This should probably live inside the metacg namespace?
If not, it should likely live in its own namespace.
What are others' opinions here?
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
This can be problematic in parallel CI runs
There was a problem hiding this comment.
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(), ""); |
There was a problem hiding this comment.
This can be problematic in parallel CI runs
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
|
Please rebase this onto the most current |
… for debugging graph edges
… not inserted into cg
… instead of node ids
01f3d3f to
ed5d7ff
Compare
| generateCG(getParsing().parseTree(), getCurrentFile()); | ||
|
|
||
| std::string cgString = dumpCG(); | ||
| std::unique_ptr<llvm::raw_pwrite_stream> file = ::createOutputFile(getInstance(), getCurrentFile(), "json"); |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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).
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:
cgfcollectorthat includes flang plugin, tests, tools, etc.cgfcollector_wrapper.shandcgfcollector_comp_wrapper.shthat simplify running the plugin.How to run: see
cgfcollector/README.mdThe 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.