[clang] [CIR] Terminate conditional regions after creation; fix glvalue conditional with a throw arm (PR #210384)

[Akshay K via cfe-commits]

================
@@ -3205,7 +3180,17 @@ LValue CIRGenFunction::emitConditionalOperatorLValue(
 
   assert((info.lhs || info.rhs) &&
          "both operands of glvalue conditional are throw-expressions?");
-  return info.lhs ? *info.lhs : *info.rhs;
+
+  // Only one arm produced an lvalue; the other was a throw-expression. The
+  // surviving arm's pointer was materialized inside the ternary's region and
+  // is not visible past the op, so address the result through the ternary's
+  // result value, which the region's cir.yield carries out.
+  LValue &survivingLV = info.lhs ? *info.lhs : *info.rhs;
+  Address survivingAddr = survivingLV.getAddress();
+  Address result(info.result, survivingAddr.getElementType(),
+                 survivingAddr.getAlignment());
+  assert(!cir::MissingFeatures::opTBAA());
+  return makeAddrLValue(result, expr->getType(), survivingLV.getBaseInfo());
----------------
kumarak wrote:

@andykaylor, The usage of the `phi` value in the test is the side-effect of this change, but the change is to fix the verifier error with the test below:
```
int &ref_cond(bool c, int &x) { return c ? x : throw 0; }
```

The previous implementation of one-arm throw returned an LValue whose pointer was materialized within the ternary's region. When the surviving arm is a local variable, that pointer is a `cir.alloca`, so it stays visible after the op and everything works, including the tests. But when the arm has to operate on its pointers (like loading a reference parameter, cir.get_member through a pointer), that value is region-local, and any use after the ternary fails verification. 

It works with the Classic codegen pipeline because the CFG is flat, and returning an LValue does not create the issue. But with CIR, the `cir.ternary` region boundary breaks the logic, and the only legal way to carry the pointer out is through yield/result. 

Please let me know if it makes it clear. I have added a regression test covering the scenario. 

https://github.com/llvm/llvm-project/pull/210384