On Fri, Mar 13, 2020 at 02:06:13AM +0100, J.W. Jagersma wrote: > I don't want to unnecessarily pessimize register outputs if it can be > avoided. And even if you do change register outputs to in+out, they > are still more likely to contain some intermediate value that you would > want to discard on throwing.
But it also may contain values that you should keep, if it threw the exception on an earlier machine instruction. > If you think of it in terms of a function call, the closest equivalent > of register vs memory outputs would be: > reg = f (); > vs. > f (&mem); > If f() throws, then in the first case, 'reg' is never assigned to. For > the second case, you can't expect 'mem' to remain unmodified. But you also cannot expect it to be modified: the old value may remain a live value. > There is also the case of "=rm" and similar which have not been > discussed so far, but are (in my experience) the most common operand > constraint. On some CISC targets, sure. Not common on load-store architectures (like most things from the last 30+ years). Segher
