andykaylor wrote: > > That would simplify the EHScopeStck handling significantly in CIR, but the > > complexity would just be moved to the FlattenCFG pass, and this would mean > > we were diverging from the classic codegen code structure. > > I'm up for the tradeoff here, the lower level alternative will make code way > harder to analyze.
I'm not certain which tradeoff you're talking about. Are you saying we should proceed with representing the `EHStackScope` in CIR? Or that we should stick with the OG-like branching through the cleanups? If we go with representing the `EHStackScope` in CIR, a lot of the code in this PR will not be needed, and so in that case I might be inclined to not commit this one at all and wait for the new cleanup representation. https://github.com/llvm/llvm-project/pull/163849 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
