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: Richard Henderson <rth at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat 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: Thu, 08 Nov 2012 20:34:22 -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>
Richard Henderson <rth@redhat.com> writes:
>
> static inline void
> -htm_abort ()
> +htm_abort_retry ()
> {
> // ??? According to a yet unpublished ABI rule, 0xff is reserved and
> // supposed to signal a busy lock. Source: andi.kleen@intel.com
> _xabort(0xff);
> }
>
> +static inline void
> +htm_abort_cancel ()
> +{
> + // ??? What's the unpublished ABI rule for this, Andi?
There is none for cancel, just for lock-is-locked (0xfe) and lock-busy (0xff)
The convention is just for easier abort profiling. The profiler (perf) can display
this abort code and it's far easier to understand if common situations
have their standard code. But you can always make up your own too.
-Andi
--
ak@linux.intel.com -- Speaking for myself only