PING this, or any of my other revisions :)
On 02/27/13 10:43, Aldy Hernandez wrote:
On 02/26/13 12:24, Richard Henderson wrote:
On 02/25/2013 02:52 PM, Aldy Hernandez wrote:
I think it's best to do this here at tmmark time, instead of at IPA-tm.
Don't we have problems when ipa inlining runs after ipa_tm, thus
creating more instrumented code later on?
No, I shouldn't think so. Inlining doesn't change the decision we
made during
IPA_TM about whether or not any one transaction doesGoIrr, which is
the *only*
bit that's relevant to eliding the uninstrumented code path during
IPA_TM, and
thus should be the only bit that's relevant to deciding that the sole
code path
is actually supposed to be instrumented or uninstrumented.
If inlining doesn't change anything then doing it at IPA time is
definitely cleaner. See attached patch.
I'm not fond of how much extra code and tests this patch is adding.
Is it
really really required? Is my analysis above wrong in some way?
Well, I know you wanted me to avoid calling ipa_uninstrument_transaction
in ipa_tm_scan_calls_transaction, but the problem is that
ipa_tm_scan_calls_transaction gets called prior to
ipa_tm_transform_transaction which is the one setting the GTMA bits.
If you're ok with this revision, I could commit it, and figure something
out for eliding the call to ipa_uninstrument_transaction as a followup
patch. I'm thinking either:
a) Something like the previous patch (which you clearly did not like),
where we remove the edges ex post facto.
b) Rearrange things somehow so we do ipa_uninstrument_transaction after
ipa_tm_scan_calls_transaction.
Aldy
