[trans-mem][rfc] Improvements to uninstrumented code paths

[Richard Henderson <rth at redhat dot com>]

I wrote the second of these patches first, and I'm uncertain about the
desirability of the first of the patches.

While working on the uninstrumented code path bulk patch, I noticed that
nested transactions within the copy of the outermost transaction were
not being processed for an uninstrumented code path, and so were only
receiving an instrumented path.  This is clearly less than ideal when
considering HTM.

Now, it seemed to me that if we're already in an uninstrumented code
path, we're extremely likely to want to stay in one.  This is certainly
true for HTM, as well as when we've selected the serialirr method.  I
can't think off hand of any other reason we'd be on the uninstrumented
code path.

Therefore the second patch arranges for all nested transactions in the
uninstrumented path to _only_ have uninstrumented paths themselves.

While reviewing the results of this second patch in detail, I noticed
that nested transactions on the instrumented code paths were not 
generating both instrumented and uninstrumented code paths.  My first
reaction was that this was a bug, and so I wrote the first patch to
fix it.

But as I was reviewing the patch to write the changelog, I began to
wonder whether the same logic concerning the original instrumented/
uninstrumented choice applies as well to the instrumented path.

Is it ever likely that we'd choose an uninstrumented path for a
nested transaction, given that we're already executing the instrumented
path for an outer transaction?

It now seems to me that the only time we'd switch from instrumented
to uninstrumented code path would be during a transaction restart,
after having selected to retry with a serialirr method.

Which means that I should apply the second patch only,

Thoughts?


r~