Move CVP before instcombine in the pass pipeline

I was investigating why LLVM was unable to remove the boundscheck
that was causing the test failure in #48066
and it turned out that the check was removable by instcombine, but
only if cvp ran first. However, we ran the passes in the opposite
order and then loop-rotated the condition away before instcombine
ran again. I think it makes sense to run cvp before instcombine to
make sure that instcombine can make use of the overflow flags inferred
by cvp. For the particular case in #48066, we also need
https://reviews.llvm.org/D140933 (and we may need it in general, since
we like to emit our conditionals as negations), but overall
this seems like a better place for cvp in our pass pipeline.

Author: Keno

src/aotcompile.cpp

@@ -863,16 +863,16 @@ void addOptimizationPasses(legacy::PassManagerBase *PM, int opt_level,
     // merging the `alloca` for the unboxed data and the `alloca` created by the `alloc_opt`
     // pass.
     PM->add(createAllocOptPass());
+    PM->add(createInstSimplifyLegacyPass());
+    PM->add(createJumpThreadingPass());
+    PM->add(createCorrelatedValuePropagationPass());
+    PM->add(createCFGSimplificationPass(basicSimplifyCFGOptions));
     // consider AggressiveInstCombinePass at optlevel > 2
     PM->add(createInstructionCombiningPass());
-    PM->add(createCFGSimplificationPass(basicSimplifyCFGOptions));
     if (dump_native)
         PM->add(createMultiVersioningPass(external_use));
     PM->add(createCPUFeaturesPass());
     PM->add(createSROAPass());
-    PM->add(createInstSimplifyLegacyPass());
-    PM->add(createJumpThreadingPass());
-    PM->add(createCorrelatedValuePropagationPass());
 
     PM->add(createReassociatePass());