This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Handle abortTransaction with RTM
- From: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "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 10:24:08 -0800
- Subject: Re: [PATCH] Handle abortTransaction with RTM
- References: <A897F08E57C2E74F92A7498CEAFBA3363FC74158@ORSMSX101.amr.corp.intel.com> <1352372508.3374.36558.camel@triegel.csb> <A897F08E57C2E74F92A7498CEAFBA3363FC744AF@ORSMSX101.amr.corp.intel.com> <1352417547.3374.39611.camel@triegel.csb> <509C5B26.6000204@redhat.com> <1352483816.3374.41718.camel@triegel.csb>
Torvald Riegel <triegel@redhat.com> writes:
> 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?.
In TSX you always come back to the outermost anyways.
Look at the nested bit in the abort code?
> 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.
I believe the current evidence is that cancel is very uncommon.
-Andi
--
ak@linux.intel.com -- Speaking for myself only