llvm dev - Jun 2018 - ModulePass cannot be registered as EarlyAsPossible

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>