[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
Fri Mar 23 10:50:11 PDT 2018
Manuel,
Thank you for the quick reply.
I am following exactly implementation design you mentioned.
All information, apart from the transformations themselves which are
communicated via a temporary file, are store in global data structures.
My question is more on the reasons why an ASTFrontendAction object must be
owned by a ScopedToolAction from the moment the ToolAction is invocation
until its end.
Which errors might occur if I do not delete each ASTFrontendAction and
reuse them across multiple invocations?
Maybe I should use a vector of FrontendActionFactory objects instead of
ASTFrontendAction?
Att.
On Fri, Mar 23, 2018 at 5:52 AM Manuel Klimek <klimek at google.com> wrote:
> FrontendActions you return are owned by the compiler; the idea is to store
> any data you need across multiple FrontendActions in a different data
> structure, and have hand pointers to those through to your FA.
>
> On Thu, Mar 22, 2018 at 3:23 PM João Paulo Labegalini de Carvalho via
> cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
>> 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
>>
> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> --
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/20180323/af1bd4f9/attachment.html>
More information about the cfe-dev
mailing list