[PATCH] D49526: Updated llvm-proto-fuzzer to execute the compiled code

[Matt Morehouse via Phabricator via cfe-commits]

morehouse added inline comments.


================
Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:115
+      make_unique<legacy::FunctionPassManager>(M.get());
+  FPasses->add(createTargetTransformInfoWrapperPass(TargetIRAnalysis()));
+
----------------
emmettneyman wrote:
> morehouse wrote:
> > morehouse wrote:
> > > Why do we add a `TargetTransformInfoWrapperPass` to both `Passes` and `FPasses`?
> > Do we need both `Passes` and `FPasses`?
> I think because we're just adding a loop vectorize pass, we don't need `FPasses`. The loop vectorize pass lives within the regular `ModulePassManager`, not the `FunctionPassManager`. I decided to put it in the code so, in the future, it would be easier to add different kinds of passes to the fuzz target. Should I remove it?
Let's remove it since it's currently unnecessary.


================
Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:135
+  std::unique_ptr<Module> M = parseIR(MemoryBufferRef(IR, "IR"), Err,
+                                           Context);
+  if (!M)
----------------
The indentation looks off.  Please fix.


================
Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:147
+  builder.setUseOrcMCJITReplacement(false);
+  builder.setMCJITMemoryManager(make_unique<SectionMemoryManager>());
+  builder.setOptLevel(OLvl);
----------------
This uses `llvm:make_unique`, which was written when LLVM used C++11.  But since LLVM now uses C++14, I think we should use `std::make_unique` instead.


================
Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:169
+  int c[] = {1};
+  
+  f(a, b, c, 1);
----------------
Remove whitespace on empty lines.

Actually, you could probably remove this line altogether since the call to `f()` can be grouped with the parameter setup above.


================
Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:184
+  CodeGenOpt::Level OLvl;
+  getOptLevel(ExtraArgs, OLvl);
+  
----------------
We're allowing the JIT opt-level to be specified on the command line, but we're hard-coding OptLevel=3 for the optimization passes.

Do we need to allow the opt-level to be specified on the command line?


Repository:
  rC Clang

https://reviews.llvm.org/D49526