PING: Re: do not pass PR_INSTRUMENTEDCODE if there is no instrumentation
Thu Mar 7 17:25:00 GMT 2013
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
More information about the Gcc-patches