Re: [patch] move GIMPLE_TRANSACTION expansion to tmmark pass

2012-11-04 Thread Aldy Hernandez
[Be not afraid, these are not new problems. This is what we've been working on off-line, reiterated here for the record.] And now that you mention it... - if (subcode & GTMA_DOES_GO_IRREVOCABLE) -flags = PR_DOESGOIRREVOCABLE | PR_UNINSTRUMENTEDCODE; - else -flags = PR_INSTRUMENTED

Re: [patch] move GIMPLE_TRANSACTION expansion to tmmark pass

2012-10-31 Thread Richard Henderson
On 2012-11-01 07:31, Aldy Hernandez wrote: > + // Hmmm, the front-end should have caught outer aborts without > + // an outer transaction. Bail and hope for the best. > + tree attrs = get_attrs_for (current_function_decl); > + if (!attrs || !lookup_attribute

Re: [patch] move GIMPLE_TRANSACTION expansion to tmmark pass

2012-10-31 Thread Aldy Hernandez
+ // The front-end should have caught outer aborts without + // an outer transaction. + gcc_unreachable (); Err, no the final check there would be if the current function includes attribute may_throw_abort_outer (sp). Just return here I think for now. Lik

Re: [patch] move GIMPLE_TRANSACTION expansion to tmmark pass

2012-10-30 Thread Richard Henderson
On 2012-10-30 05:32, Aldy Hernandez wrote: > + // If we have a ``_transaction_cancel [[outer]]'', there is only > + // one abnormal edge: to the transaction marked OUTER. > + tree arg = gimple_call_arg (stmt, 0); > + if (TREE_CODE (arg) == INTEGER_CST) > + { > + if (TR

[patch] move GIMPLE_TRANSACTION expansion to tmmark pass

2012-10-29 Thread Aldy Hernandez
What was supposed to be a simple fix, turned out to be a nightmare... I am working on adding an uninstrumented code path for TM, in expectation of hardware TM. This means that we eventually want to generate something like this: prop = _ITM_beginTransaction(PR_multiwayCode);