[llvm-dev] ModulePass cannot be registered as EarlyAsPossible

Björn Pettersson A via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 13 04:41:23 PDT 2018


Yes, sorry that I wasn’t very clear about that, but the hack in opt.cpp only works when using opt. We are doing the “early rewrites” when using another frontend than clang, and in that case we are running the opt/llc binaries standalone after the frontend.

I’m not sure, but maybe it is possible to do something similar in EmitAssemblyHelper::CreatePasses (in clang/lib/CodeGen/BackendUtil.cpp), if you want to do it in clang.

/Björn

From: Son Tuan VU <sontuan.vu119 at gmail.com>
Sent: den 12 juni 2018 19:54
To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
Subject: Re: [llvm-dev] ModulePass cannot be registered as EarlyAsPossible

Thanks Björn for your answer.
So your way of doing this implies that we have to use opt, what if we want to use clang instead? I mean, instead of
clang -O0 -emit-llvm -S foo.c -o foo.ll
opt -O1 -S foo.ll -o foo_opt.ll
we would have
clang -O1 -emit-llvm -S foo.c -o foo_opt.ll
I guess this requires me to find the right place in clang to add the same code as yours in opt?


Son Tuan Vu

On Tue, Jun 12, 2018 at 6:11 PM, Björn Pettersson A <bjorn.a.pettersson at ericsson.com<mailto:bjorn.a.pettersson at ericsson.com>> wrote:
I let someone else answer about if it is a bug or not.

Anyway, in our out-of-tree-target we have some module passes that we want to run early in opt.
Our way of doing it is to use a hack in tools/opt/opt.cpp like this:

diff --git a/tools/opt/opt.cpp b/tools/opt/opt.cpp
index 43771d5d75b..2a08ce1a448 100644
--- a/tools/opt/opt.cpp
+++ b/tools/opt/opt.cpp
@@ -608,6 +608,16 @@ int main(int argc, char **argv) {
   OptCustomPassManager Passes;
   bool AddOneTimeDebugifyPasses = EnableDebugify && !DebugifyEach;
+  // EarlyRewriter must run very early. Since we made it a
+  // ModulePass, there is no standard way to make this happen (the standard ways
+  // only work for FunctionPasses). Run the pass in a separate Passmanager
+  // before any other pass.
+  if (TM && TM->runEarlyModulePasses()) {
+    legacy::PassManager FirstPasses;
+    addPass(FirstPasses, static_cast<ModulePass*>(createEarlyRewriterPass()));
+    FirstPasses.run(*M);
+  }
+
   // Add an appropriate TargetLibraryInfo pass for the module's triple.
   TargetLibraryInfoImpl TLII(ModuleTriple);


Note the FirstPasses.run(*M), which means that those first passes are run directly.
And then we have added the runEarlyModulePasses() hook in TargetMachine that will make sure we add and run the FirstPasses pass manager when compiling for our target.

Regards,
Björn

From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Son Tuan VU via llvm-dev
Sent: den 12 juni 2018 15:46
To: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: [llvm-dev] ModulePass cannot be registered as EarlyAsPossible

Hello all,

I've followed the example in https://github.com/CompilerTeaching/SimplePass/blob/master/SimplePass.cc in order to create a custom pass.

The pass needs to be added before any transformation, so I used EP_EarlyAsPossible extension point to register it.  Furthermore, I need to access to every GlobalVariable in the IR, so my pass has to be a ModulePass, like this:

  struct MyPass : public ModulePass {
     static char ID;
     MyPass(): ModulePass(ID) {}
     virtual bool runOnModule(Module &M) {...}
  ...
  }

However, every time I try to access to the Module object M inside runOnModule(), clang just crashes.  Even a debug message like outs() << M.getName() << '\n'; would cause a segfault. So am I doing something wrong, like EP_EarlyAsPossible is really not to be used with ModulePasses, or is this rather a bug?

In case this is not a bug, what would be the best way to manipulate an IR Module as it is coming right out of the frontend?

Thanks for your help,

Son Tuan Vu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180613/786fc582/attachment.html>


More information about the llvm-dev mailing list