> 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?
StilesCrisis•1h ago
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.
fluoridation•58m ago
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.
fooker•16m ago
Throw in a couple of barriers.
gmueckl•58m ago
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.
im3w1l•1h ago
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?
StilesCrisis•1h ago
fluoridation•58m ago
fooker•16m ago
gmueckl•58m ago