PING: Re: do not pass PR_INSTRUMENTEDCODE if there is no instrumentation

[Aldy Hernandez <aldyh@redhat.com>]

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