Incorporate review feedback

Author: andykaylor

clang/docs/ClangIRCodeDuplication.rst

@@ -64,8 +64,11 @@ problem.
 We have discussed various ways that major classes such as CGCXXABI/CIRGenCXXABI
 could be refactored to allow parts of there implementation to be shared today
 through inheritence and templated base classes. However, this may prove to be
-wasted effort when the permanent solution is developed, so we have decided that
-it is better to accept significant amounts of code duplication now, and defer
+wasted effort when the permanent solution is developed. Also, deferring this
+kind of intertwined implementation prevents introducing cross-dependencies that
+would make it more difficult to remove one IR code generation implementation
+without degrading the quality of the other. Therefore, we have decided that it
+is better to accept significant amounts of code duplication now, and defer
 this type of refactoring until it is clear what the permanent solution will be.
 
 Mitigation Through Testing
@@ -93,7 +96,8 @@ implementation when these tests fail.
 As the CIR implementation gets closer to the goal of IR that is semantically
 equivalent to the LLVM IR produced by the classic codegen, we would like to
 enhance the CIR tests to perform some automatic verification of the equivalence
-of the generated LLVM IR, perhaps using a tool such as Alive2.
+of the generated LLVM IR, perhaps using a combination of tools such as `opt
+-pass-normalize` and Alive2.
 
 Eventually, we would like to be able to run all existing classic codegen tests
 using the CIR path as well.
@@ -113,8 +117,9 @@ and immediate benefit to doing so.
 
 Over time, we expect to progressively raise the CIR representation to a higher
 level and remove low level details, including ABI-specific handling from the
-dialect. However, having a working implementation in place makes it easier to
-verify that the high level representation and subsequent lowering are correct.
+dialect. (See the "Long Term Vision" section below for more  details.) Having
+a working implementation in place makes it easier to verify that the
+high-level representation and subsequent lowering are correct.
 
 Mixing With Other Dialects
 ==========================
@@ -137,8 +142,9 @@ Other Consumers of CIR and MLIR
 
 We must also consider that we will not always be lowering CIR to LLVM IR. CIR,
 usually mixed with other dialects, will also be directed to offload targets
-and other code generators through interfaces that are opaque to Clang. We must
-still produce semantically correct CIR for these consumers.
+and other code generators through interfaces that are opaque to Clang, such as
+SPIR-V and MLIR core dialects. We must still produce semantically correct CIR
+for these consumers.
 
 Long Term Vision
 ================
@@ -147,7 +153,10 @@ As the CIR implementation matures, we will eliminate target-specific handling
 from the high-level CIR generated by Clang. The high-level CIR will then be
 progressively lowered to a form that is closer to LLVM IR, including a pass
 that inserts ABI-specific handling, potentially representing the target-specific
-details in another dialect.
+details in another dialect. More complex transformations, such as library-aware
+idiom recognition or advanced loop representations—may occur later in the
+compilation pipeline through additional passes, which can be controlled by
+specific compiler flags.
 
 As we raise CIR to this higher level implementation, there will naturally be
 less code duplication, and less need to have the same logic repeated in the