[cfe-dev] Running multiple ASTFrontendAction actions over list of source files

João Paulo Labegalini de Carvalho via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 22 07:23:34 PDT 2018


Hi,

My name is João (some kind of brazilian version for John) and I am
implementing a tool based using the libTooling framework. The goal of the
tool is to performe Source-To-Source code transformations for later
analysis/instrumentation through a LLVM Pass. The transformations will
basically "mark" the start and end of OMPParallelFor loop bodies. The LLVM
Pass will instrument all load/store instructions and hand their pointer
operand to my runtime library. The runtime will attempt to detect
loop-carried dependencies.

Each transformation must be able to see the result of previous
transformations, therefore I have implemented a slightly modified version
of the ClangTool. I am attaching the source code containing the run method
of my custom ClangTool class (a.k.a. CheckerTool).

Right now my tool is able to successfully run multiple ASTFrontendAction
actions over a single source file. However, as soon as ToolInvocation
finishes processing a file, my custom ASTFrontendAction is destroyed. By
inspecting the code of ToolInvocation::runInvocation method at
lib/Tooling/Tooling.cpp I have found the culprit. The ToolInvocation object
takes ownership of my ASTFrontendAction through a std::unique_ptr stored in
the object ScopedToolAction. Looking through the history of the Tooling.cpp
in the llvm/clang project on github I have found the commit which
introduced such behavior (
https://github.com/llvm-mirror/clang/commit/14a192435425af39e7f32b6e71613f9357e995f7#diff-bf9ab6da20a9d03d965b034c8c30a010
).

The comment associated with such change tries to explain why it is
necessary to delete the ToolAction as soon as the invocation ends, however
I am failing to understand it. I would greatly appreciate if anyone of you,
far more educated than myself on the inner workings of clang, could explain
to me the mentioned comment ("ToolAction can have lifetime requirements for
Compiler or its members.....").

I was able to accomplish my goal by replacing the std:unique_ptr by a
"conventional" pointer in the ToolInvocation::runInvocation method.
Nonetheless, I fear for the completeness of my work-around.

Best regards,
-- 
João Paulo L. de Carvalho
Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
jaopaulolc at gmail.com
joao.carvalho at ic.unicamp.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180322/b7fbf84b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CheckerTool.cpp
Type: text/x-c++src
Size: 11253 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180322/b7fbf84b/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CheckerTool.h
Type: text/x-chdr
Size: 1427 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180322/b7fbf84b/attachment.h>


More information about the cfe-dev mailing list