[PATCH] D80344: [Windows SEH]: HARDWARE EXCEPTION HANDLING (MSVC -EHa) - Part 1

Thu Sep 17 21:11:31 PDT 2020

rjmccall added a comment.

In D80344#2280617 <https://reviews.llvm.org/D80344#2280617>, @tentzen wrote:

> Hi, John, thank you for reviewing this patch and providing feedback.
> regarding your comments:
>
> 1, In the RFC thread early, Reid K (the major contributor of Windows SEH/EH support) had agreed that "the value proposition is clear and large".

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.

> 2,  could you elaborate why do you think "block-level tracking state / control flow is potentially really problematic for LLVM.."? Could you be more specific or provide some examples?

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.

> Remainder that this design also relies on existent EH framework to compute block state, and it has passed MSVC SEH suite that contains many complicated SEH cases.

Does it pass under all combinations of optimization and code-generation settings?  How do LLVM contributors ensure that this test suite continues to pass?

> 3, I don't understand your concern "the way we handle cleanups in Clang today is sufficiently "atomic" in design to accommodate this".  From Cleanup perspective, there is no difference between HW exception and non-HW exceptions.  The key of handling HW exception is to catch exceptions on those faulty / memory instructions.  Once it's caught the cleanup process is identical to non-HW exception.  again, could you elaborate further?

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.

> Finally, regarding naming/option in the code, -EHa or "Asynchronous" is the terminology used in MSVC in Windows.  Programmers who use/care this feature should know it well as it's the feature to match MSVC in Windows.

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.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80344/new/

https://reviews.llvm.org/D80344