[turboprop] Fix DCHECK in SetOptimizedCode

With --always-opt / %OptimizeFunctionOnNextCall it is also possible
that we see CompileOptimizedConcurrent marker when we install optimized
code. For example,
1. Mark function for concurrent optimization and trigger a job.
2. Create a new JSClosure and with --always-opt we optimize concurrently
and install optimized code. This clears the marker.
3. The installed optimized code is GCed or deopts and we re-mark the
function for concurrent optimization.
4. The optimize job created in step 1 finishes.

Bug: v8:11139, chromium:1146714
Change-Id: Ic2aa456b76d74d939441a84528bc5c27d9ea9381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529450Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71126}

src/objects/feedback-vector.cc

@@ -390,11 +390,10 @@ void FeedbackVector::SetOptimizedCode(Handle<FeedbackVector> vector,
          (vector->optimized_code().kind() == CodeKind::TURBOPROP &&
           code->kind() == CodeKind::TURBOFAN));
   // TODO(mythria): We could see a CompileOptimized marker here either from
-  // tests that use %OptimizeFunctionOnNextCall or because we re-mark the
-  // function for non-concurrent optimization after an OSR. We should avoid
-  // these cases and also check that marker isn't kCompileOptimized.
-  DCHECK(vector->optimization_marker() !=
-         OptimizationMarker::kCompileOptimizedConcurrent);
+  // tests that use %OptimizeFunctionOnNextCall, --always-opt or because we
+  // re-mark the function for non-concurrent optimization after an OSR. We
+  // should avoid these cases and also check that marker isn't
+  // kCompileOptimized or kCompileOptimizedConcurrent.
   vector->set_maybe_optimized_code(HeapObjectReference::Weak(*code));
   int32_t state = vector->flags();
   state = OptimizationTierBits::update(state, GetTierForCodeKind(code->kind()));