[PATCH] D39555: Introduce llvm-opt-fuzzer for fuzzing optimization passes

[Igor Laevsky via Phabricator via llvm-commits]

igor-laevsky added inline comments.


================
Comment at: lib/FuzzMutate/FuzzerCLI.cpp:48-49
       Args.push_back("-O0");
+    } else if (Opt.startswith("instcombine")) {
+      Args.push_back("-passes=instcombine");
     } else if (Opt.startswith("O")) {
----------------
bogner wrote:
> We should add a new/separate handleExecNameEncodedFEOpts or handleExecNameEncodedPassList instead of adding this to BE opts. This fuzzer shouldn't need the backend options AFAIK.
Yes, I agree. I think best option is to write parametrised version of the `handleExecNameEncodedBEOpts` which would receive the desired mapping between "exec" options and command line options. However I would prefer to do this in a separate change to not clobber this one with the refactoring. 
Do you think we can leave this code as-is for the initial submission?


================
Comment at: tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp:134-139
+  // Set up target dependant options
+  //
+
+  M->setTargetTriple(TM->getTargetTriple().normalize());
+  M->setDataLayout(TM->createDataLayout());
+  setFunctionAttributes(TM->getTargetCPU(), TM->getTargetFeatureString(), *M);
----------------
bogner wrote:
> These don't change from input to input do they? We should probably set this up in the initialize function.
I don't think we can do this. This is freshly created module, so we need to set correct target parameters during each invocation.



================
Comment at: tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp:141-160
+  // Create pass pipeline
+  //
+
+  PassBuilder PB(TM.get());
+
+  LoopAnalysisManager LAM;
+  FunctionAnalysisManager FAM;
----------------
bogner wrote:
> Similarly here - we probably don't need to reconfigure the pass pipeline every time.
That was what I did initially. However libFuzzer complained about "number of mallocs didn't match number of free's" and disabled "LeakDetection after each iteration". 

I suspect that somewhere in the pass manager something accumulates some state on each run, maybe to cache analysis results or something in this way. I don't really have good knowledge of this area, but having pass manager initialization on each iteration seems like a bulletproof solution from this kind of problems. 


https://reviews.llvm.org/D39555