On 02/27/2013 08:43 AM, Aldy Hernandez wrote:
> + * trans-mem.c (expand_transaction): Do not set PR_INSTRUMENTEDCODE
> + if GTMA_HAS_NO_INSTRUMENTATION.
> + (generate_tm_state): Keep GTMA_HAS_NO_INSTRUMENTATION bit.
> + (ipa_tm_transform_transaction): Set GTMA_HAS_NO_INSTRUMENTATION
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 run
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
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 w
Whoops, wrong patch. This is the latest revision.
On 02/25/13 16:48, Aldy Hernandez wrote:
On 02/22/13 11:27, Richard Henderson wrote:
On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
ever enter expand_block_tm(), but perhaps w
On 02/22/13 11:27, Richard Henderson wrote:
On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
ever enter expand_block_tm(), but perhaps we could do a little better as
with the attached patch.
I assume you meant "never enter" ther
On 02/21/2013 02:14 PM, Aldy Hernandez wrote:
> I suppose we could cheat and avoid passing PR_INSTRUMENTEDCODE if we
> ever enter expand_block_tm(), but perhaps we could do a little better as
> with the attached patch.
I assume you meant "never enter" there.
Yes, you don't need to "accumulate" GT
It has come to my attention, by..ahem...you, that in handling the
testcase from my previous patch:
__transaction_relaxed { __asm__(""); }
...if we avoid instrumentation altogether, we shouldn't lie to the
run-time and pass PR_INSTRUMENTEDCODE.
I suppose we could cheat and avoid passing PR_
