tentzen added a comment. Thank you for prompt reply again.
> [rjmccall] And I agree with him that the potential benefits are substantial. > I'm just saying that one barely-trafficked RFC thread is not evidence of a > community consensus. OK, thanks. it's good to know you are also supportive in adding this feature. > [rjmccall] As I understand it, you are creating implicit edges within the > function to the active SEH handler (potentially part of the same function) > from arbitrary places within covered basic blocks, turning basic blocks from > a single-entry single-(internal-)exit representation to a single-entry > multiple-exit representation. That is a huge change. How do you expect LLVM > transformations to preserve or merge this information across blocks? How do > you expect transformations to not move code between blocks in problematic > ways, or reorder code within blocks in ways that will suddenly be visible to > the optimizer? These are the standard objections to supporting features like > this, that they have basically unspecified behavior and appear to work by > good intentions and happy thoughts. There is absolutely NO explicit edge added in this design. You misunderstood the term of SEME here. It refers to a SEH scope-region of many blocks that can have multi-blocks jumping out of this region, not multi-branches jumping out of a block. Since blocks in LLVM are already 'completely' connected by Control Flow (no lexical concept at all before layout), there is nothing we need to do to //build //this SEME region. For LLVM transformations/optimizations, the only constrain added is **volatile** attribute on memory operations within a SEH region. As described earlier, it's a little sub-optimal, but given that the amount of code directly under a SEH scope is very small, the impact to overall code quality is minor. Volatile-ness is robust as it's one fundamental attribute that is expected to be honored by entire framework. > [rjmccall] Does it pass under all combinations of optimization and > code-generation settings? How do LLVM contributors ensure that this test > suite continues to pass? Yes. this is just the first patch. there will be second patch to land LLVM code-gen part in, then 3rd patch to add some test cases (Ex, xcpt4u.c from MSVC). Without option -EHa, the patch is a zero-impact change for now. > [rjmccall] There is a major difference between HW exceptions and non-HW > exceptions, which is that non-HW exceptions are observed only at call sites. > It is quite easy to write code in IRGen that works because the code emitted > at a certain point isn't totally arbitrary still not completely sure what you are referring to. let me guess. Are you concerned that the Cleanup mechanism of a SEH region may not be setup properly if there is no call instruction in the region? This is actually a good question. The answer is that the presence of seh.try.begin() intrinsic will ensure that a Cleanup stack is established properly because there is an EH edge built for seh.try.begin() automatically. hope this answer your concern here. > [rjmccall] Yes, but it's not known well to all the compiler developers who > are reading and maintaining the Clang codebase. I'm not saying you should > rename the command-line flag, I'm asking that you not just say "EHa" in > comments and identifiers. Ok, no problem. more comments will be added. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80344/new/ https://reviews.llvm.org/D80344 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
