> Structured exception handling (SEH) is a Microsoft extension to C and C++ to handle certain exceptional code situations, such as hardware faults, gracefully. Although Windows and Microsoft C++ support SEH, we recommend that you use ISO-standard C++ exception handling in C++ code. It makes your code more portable and flexible. However, to maintain existing code or for particular kinds of programs, you still might have to use SEH.
Hm. I found this (that memory must be stable wherever a SEH exception could be thrown) surprising, because I thought the unwind information generated by the compiler should be able to reconstruct all the correct variable values during stack unwinding.
Specifying /EHa and trying to handle all exceptions by using catch(...) can be dangerous. In most cases, asynchronous exceptions are unrecoverable and should be considered fatal. Catching them and proceeding can cause process corruption and lead to bugs that are hard to find and fix.
Even though Windows and Visual C++ support SEH, we strongly recommend that you use ISO-standard C++ exception handling (/EHsc or /EHs). It makes your code more portable and flexible. There may still be times you have to use SEH in legacy code or for particular kinds of programs. It's required in code compiled to support the common language runtime (/clr), for example. For more information, see Structured exception handling.
We recommend that you never link object files compiled using /EHa to ones compiled using /EHs or /EHsc in the same executable module. If you have to handle an asynchronous exception by using /EHa anywhere in your module, use /EHa to compile all the code in the module. You can use structured exception handling syntax in the same module as code that's compiled by using /EHs. However, you can't mix the SEH syntax with C++ try, throw, and catch in the same function.
C++ exceptions are SEH exceptions with a reserved opcode though. So the answer is "yes", "no", and "obviously" depending on how knowledgeable you are about the platform.
> No, that’s not why the /EHa option results in less efficient code. The possibility that any memory access or arithmetic operation could trigger an exception significantly impairs optimization opportunities. It means that all variables must be stable at the point memory accesses occur.
This is a good insight but I feel like stopping the analysis here is a little bit too early. We should also think about what they actually wanted to achieve. Did they actually need all variables to be stable at the point of any memory access? Maybe they want 90% of the benefits at 10% of the cost somehow?
> Did they actually need all variables to be stable at the point of any memory access?
One of the most important optimizations that a compiler can do is keeping a variable in a register and never even bother letting it hit memory in the first place. If every variable must get its own RAM address and the value at that RAM address must be faithful to a variable's "true" value at any given instruction, we should expect our software to slow down by an order of magnitude or two.
I don’t think there is a version of UB that gives you a predictable 90%, though. Either your program is exception-safe or it’s not. There’s no such thing as 90% safe.
A possible compromise could be to be able to tell the compiler, "I don't care about structured exceptions anywhere else, so do all your instruction reordering stuff there, but this one section of code I know could throw structured exceptions, so be more conservative here." It might need to generate duplicated code for some functions, though.
The majority of a program's runtime is usually spent in only a tiny section of its code. That is where optimization benefits are. If it helps to separate out that code and compile it with different compiler switches, the additional maintenance burden for the program structure and build system might be acceptable.
Go look at profiles for programs which have been written with performance in mind. Operating systems, databases, game engines, web servers, some compilers, video/audio/3d editing packages come to mind. I 100% guarantee these programs do not spend the majority of their runtimes in a tiny section of code. What you said is nearly-unilaterally untrue, at least for programs that care about real performance.
That's not a useful description of desktop "creative" software. Even though it might be true for audio that in many cases, the majority of the run time is spent handling the "process callback" from the audio subsystem, once the user starts actually working on things, the slow parts of the code (and the ones that impede the user or degrade their experience) are far removed from that core. This is a little less true of visual applications (video, drawing, image editing etc.) but I would imagine that similar considerations apply there too.
For context:
https://learn.microsoft.com/en-us/cpp/cpp/structured-excepti...
> Structured exception handling (SEH) is a Microsoft extension to C and C++ to handle certain exceptional code situations, such as hardware faults, gracefully. Although Windows and Microsoft C++ support SEH, we recommend that you use ISO-standard C++ exception handling in C++ code. It makes your code more portable and flexible. However, to maintain existing code or for particular kinds of programs, you still might have to use SEH.
Hm. I found this (that memory must be stable wherever a SEH exception could be thrown) surprising, because I thought the unwind information generated by the compiler should be able to reconstruct all the correct variable values during stack unwinding.
TIL
More details;
Mixing C (structured) and C++ exceptions - https://learn.microsoft.com/en-us/cpp/cpp/mixing-c-structure...
Handle structured exceptions in C++ - https://learn.microsoft.com/en-us/cpp/cpp/exception-handling...
For even more fun, Microsoft C++ implementation of setjmp/longjmp calls dtors of lexically scoped objects properly during stack unwinding (when compiled with proper switches) - https://learn.microsoft.com/en-us/cpp/cpp/using-setjmp-longj...
Finally Important caveats from - https://learn.microsoft.com/en-us/cpp/build/reference/eh-exc...
Specifying /EHa and trying to handle all exceptions by using catch(...) can be dangerous. In most cases, asynchronous exceptions are unrecoverable and should be considered fatal. Catching them and proceeding can cause process corruption and lead to bugs that are hard to find and fix.
Even though Windows and Visual C++ support SEH, we strongly recommend that you use ISO-standard C++ exception handling (/EHsc or /EHs). It makes your code more portable and flexible. There may still be times you have to use SEH in legacy code or for particular kinds of programs. It's required in code compiled to support the common language runtime (/clr), for example. For more information, see Structured exception handling.
We recommend that you never link object files compiled using /EHa to ones compiled using /EHs or /EHsc in the same executable module. If you have to handle an asynchronous exception by using /EHa anywhere in your module, use /EHa to compile all the code in the module. You can use structured exception handling syntax in the same module as code that's compiled by using /EHs. However, you can't mix the SEH syntax with C++ try, throw, and catch in the same function.
C++ exceptions are SEH exceptions with a reserved opcode though. So the answer is "yes", "no", and "obviously" depending on how knowledgeable you are about the platform.
> No, that’s not why the /EHa option results in less efficient code. The possibility that any memory access or arithmetic operation could trigger an exception significantly impairs optimization opportunities. It means that all variables must be stable at the point memory accesses occur.
This is a good insight but I feel like stopping the analysis here is a little bit too early. We should also think about what they actually wanted to achieve. Did they actually need all variables to be stable at the point of any memory access? Maybe they want 90% of the benefits at 10% of the cost somehow?
> Did they actually need all variables to be stable at the point of any memory access?
One of the most important optimizations that a compiler can do is keeping a variable in a register and never even bother letting it hit memory in the first place. If every variable must get its own RAM address and the value at that RAM address must be faithful to a variable's "true" value at any given instruction, we should expect our software to slow down by an order of magnitude or two.
I don’t think there is a version of UB that gives you a predictable 90%, though. Either your program is exception-safe or it’s not. There’s no such thing as 90% safe.
A possible compromise could be to be able to tell the compiler, "I don't care about structured exceptions anywhere else, so do all your instruction reordering stuff there, but this one section of code I know could throw structured exceptions, so be more conservative here." It might need to generate duplicated code for some functions, though.
Throw in a couple of barriers.
The majority of a program's runtime is usually spent in only a tiny section of its code. That is where optimization benefits are. If it helps to separate out that code and compile it with different compiler switches, the additional maintenance burden for the program structure and build system might be acceptable.
Go look at profiles for programs which have been written with performance in mind. Operating systems, databases, game engines, web servers, some compilers, video/audio/3d editing packages come to mind. I 100% guarantee these programs do not spend the majority of their runtimes in a tiny section of code. What you said is nearly-unilaterally untrue, at least for programs that care about real performance.
That's not a useful description of desktop "creative" software. Even though it might be true for audio that in many cases, the majority of the run time is spent handling the "process callback" from the audio subsystem, once the user starts actually working on things, the slow parts of the code (and the ones that impede the user or degrade their experience) are far removed from that core. This is a little less true of visual applications (video, drawing, image editing etc.) but I would imagine that similar considerations apply there too.
> The majority of a program's runtime is usually spent in only a tiny section of its code. That is where optimization benefits are.
People who keep repeating this have only ever either looked at the profiles of zero or one types of programs.