This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Handle abortTransaction with RTM
- From: Torvald Riegel <triegel at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "Kleen, Andi" <andi dot kleen at intel dot com>, "Lai, Konrad" <konrad dot lai at intel dot com>, Aldy Hernandez <aldyh at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 09 Nov 2012 18:56:56 +0100
- Subject: Re: [PATCH] Handle abortTransaction with RTM
- References: <A897F08E57C2E74F92A7498CEAFBA3363FC74158@ORSMSX101.amr.corp.intel.com> <firstname.lastname@example.org> <A897F08E57C2E74F92A7498CEAFBA3363FC744AF@ORSMSX101.amr.corp.intel.com> <email@example.com> <509C5B26.firstname.lastname@example.org>
On Thu, 2012-11-08 at 17:23 -0800, Richard Henderson wrote:
> + // Honor an abort from abortTransaction.
> + else if (htm_abort_is_cancel(ret))
> + return a_abortTransaction | a_restoreLiveVariables;
The problem is that we cannot reliably detect whether an abort with a
certain abort reason code really means that we got canceled. A nested
transaction is one example: how do we distinguish whether the nested or
the outermost transaction were canceled?.
Another example is transaction_pure or tm_wrapper code that might reuse
the same abort reason for explicit aborts: we would like to allow
malloc() calls in transactions, but if malloc uses transactions with
explicit aborts, we might abort a transaction without a cause.
It might be possible to avoid that by carefully specifying the rules for
abort reasons, which of those can be used in nested transactions, and so
on. But I'm not aware of any specification like that, and it seems to
likely be a pretty fragile approach.
Thus, there are two options for how to handle transactions that may
abort: Either execute them transactionally the first time, and do an
explicit HTM abort on transaction_cancel that tells libitm not not retry
as HW transaction, or execute such transactions always as SW
transactions. Which of these two options is better depends on how
frequently transaction_cancel would actually be called. If it's
infrequent, then trying to run as HW transactions might be better.