RFC: Exception Handling Proposal II

I don't see how you can have dominance between a normal block and a
cleanup block. Clean-up landing pads should never use user code (since
they don't exist in userland).

[...]

In essence, in compiler generated landing pads, you should never
generate a use of user values. But if XYZ is user code, it's user
problem. :wink:

I am just catching up, and I may miss some context, but that statement sounds incorrect to me.

Part of the value of the landing-pad EH design back when we invented that scheme for Itanium was to allow for "compensation code" in landing pads that could restore user values. Consider this:

int x = 0;
int y = 1;
int z = 2;
try {
   foo()
   x = y;
   bar();
   x = z;
} catch (...) {
   show(x);
}

In that scenario, it would be legitimate to eliminate the x=y and x=z from the basic blocks in the main body, as long as you insert compensation code in the landing pads associated with foo() and bar() calls. In essence, you move the "x=y" to the landing pad. The move is compiler-generated, but the value being referenced is still a user value.

Therefore, I believe that clean-up landing pads may write or use user values. I have not read enough context to know whether this has any impact on the proposal or not.

Regards
Christophe

Hi Christophe.

I was not saying it's illegal, just that would be good to keep the
separation between compiler code and user code, to make it easier for
optimization passes to determine the intended call graph and the
exception one.

cheers,
--renato