On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
On 08/22/2013 02:57 PM, Torvald Riegel wrote:
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
+ /* Store edi for future HTM fast path retries. We use a stack slot
+
Torvald Riegel trie...@redhat.com writes:
On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
On 08/22/2013 02:57 PM, Torvald Riegel wrote:
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
+/* Store edi for future
Committed as r202101.
This cause a bootstrap failure:
...
libtool: compile: /opt/gcc/build_w/./gcc/xg++ -B/opt/gcc/build_w/./gcc/
-nostdinc++ -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
On Fri, 2013-08-30 at 16:49 +0200, Rainer Orth wrote:
Torvald Riegel trie...@redhat.com writes:
On Mon, 2013-08-26 at 09:49 -0700, Richard Henderson wrote:
On 08/22/2013 02:57 PM, Torvald Riegel wrote:
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
On 08/22/2013 11:39 AM,
On Fri, 30 Aug 2013, Dominique Dhumieres wrote:
Committed as r202101.
This cause a bootstrap failure:
on x86_64-apple-darwin10.
And FreeBSD. Your fix also restored bootstrap there. Thanks
for the quick reaction, and to Dominique and Rainer for their
reports.
Gerald
On 08/22/2013 02:57 PM, Torvald Riegel wrote:
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
+ /* Store edi for future HTM fast path retries. We use a stack slot
+ lower than the jmpbuf so that the jmpbuf's rip field will
Attached is an updated patch. Changes explained below.
On Wed, 2013-08-21 at 10:50 -0700, Richard Henderson wrote:
-#if defined(USE_HTM_FASTPATH) !defined(HTM_CUSTOM_FASTPATH)
+#ifdef USE_HTM_FASTPATH
// HTM fastpath. Only chosen in the absence of transaction_cancel to
allow
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
+ /* Store edi for future HTM fast path retries. We use a stack slot
+lower than the jmpbuf so that the jmpbuf's rip field will overlap
+with the proper return address on the stack. */
+ movl%edi, -64(%rsp)
You havn't
On Thu, 2013-08-22 at 12:05 -0700, Richard Henderson wrote:
On 08/22/2013 11:39 AM, Torvald Riegel wrote:
+ /* Store edi for future HTM fast path retries. We use a stack slot
+ lower than the jmpbuf so that the jmpbuf's rip field will overlap
+ with the proper return address on
This patch adds a custom HTM fast path for RTM on x86_64, which moves
the core HTM fast path bits from gtm_thread::begin_transaction into the
x86-specific ITM_beginTransaction implementation. It extends/changes
the previous patch by Andi:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01228.html
Torvald Riegel trie...@redhat.com writes:
+#endif
leaq8(%rsp), %rax
- subq$56, %rsp
- cfi_def_cfa_offset(64)
+ subq$64, %rsp
+ cfi_def_cfa_offset(72)
I don't see why you did this change and the addq change below.
The rest seems reasonable to me, although I
On Wed, 2013-08-21 at 10:14 -0700, Andi Kleen wrote:
Torvald Riegel trie...@redhat.com writes:
+#endif
leaq8(%rsp), %rax
- subq$56, %rsp
- cfi_def_cfa_offset(64)
+ subq$64, %rsp
+ cfi_def_cfa_offset(72)
I don't see why you did this change and the addq change
That's true for x86, but it seems that for s390, we can't easily put the
xbegin/tbegin into the C++ code because of floating point register
save/restore issues. The added complexity on the x86 side seemed to be
a reasonable price for having a general HTM fast path retry handling on
the C++
-#if defined(USE_HTM_FASTPATH) !defined(HTM_CUSTOM_FASTPATH)
+#ifdef USE_HTM_FASTPATH
// HTM fastpath. Only chosen in the absence of transaction_cancel to allow
// using an uninstrumented code path.
// The fastpath is enabled only by dispatch_htm's method group, which uses
@@
On Wed, 2013-08-21 at 19:41 +0200, Andi Kleen wrote:
That's true for x86, but it seems that for s390, we can't easily put the
xbegin/tbegin into the C++ code because of floating point register
save/restore issues. The added complexity on the x86 side seemed to be
a reasonable price for
On 08/21/2013 10:14 AM, Andi Kleen wrote:
The rest seems reasonable to me, although I haven't tried to untangle
the full dependencies between C++ and asm code for retries.
It would be likely cleaner to just keep the retries fully
in C++ like the original patch did. There's no advantage
of
16 matches
Mail list logo
