[llvm-reduce] Specify ShouldPreserveUseListOrder for internal .ll dumps

[markus]

Summary

I recently ran into a case where I was trying to reduce a .bc file and the interestingness test I had written reported that the input was interesting when run in isolation but when running llvm-reduce it failed the initial sanity check before reduction starts. Turns out that internally llvm-reduce only deals with .ll files and does not set the ShouldPreserveUseListOrder option when producing these. For this rare case setting the option made the difference between being able to reduce or not.

I suggest that we either always set that option or alternatively add a command line option to have it set.

[fhahn]

This makes sense to me, but I think this is another motivation to use bitcode as default for temporary files (flip the default of TmpFilesAsBitcode to true)

[markus]

In D118585#3283347, @fhahn wrote:

This makes sense to me, but I think this is another motivation to use bitcode as default for temporary files (flip the default of TmpFilesAsBitcode to true)

Ah, I was not aware we had an option for bitcode (I see now it has been added somewhat recently). I agree it would make more sense to have that as default or perhaps even better that the intermediate format follows the format of the input file.
It is a bit unfortunate though that this option does not show when one does a llvm-reduce --help (I believe the same is true for a few of the other options as well).

[aeubanks]

does bitcode preserve use list orders?

but anyway this patch lgtm

llvm/tools/llvm-reduce/ReducerWorkItem.cpp

bool verifyReducerWorkItem(const ReducerWorkItem &MMM, raw_fd_ostream *OS) {
   return false;
 }
 
 void ReducerWorkItem::print(raw_ostream &ROS, void *p) const {
   if (MF) {
     printMIR(ROS, *M);
     printMIR(ROS, *MF);
   } else {
-    M->print(ROS, nullptr);
+    M->print(ROS, /*AssemblyAnnotationWriter=*/nullptr,
+             /*ShouldPreserveUseListOrder=*/true);
   }
 }