This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] libitm: Add custom HTM fast path for RTM on x86_64.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, "Kleen, Andi" <andi dot kleen at intel dot com>
- Date: Wed, 21 Aug 2013 19:53:42 +0200
- Subject: Re: [PATCH] libitm: Add custom HTM fast path for RTM on x86_64.
- References: <1377094606 dot 3196 dot 4901 dot camel at triegel dot csb> <874najhsps dot fsf at tassilo dot jf dot intel dot com> <1377106398 dot 3196 dot 5110 dot camel at triegel dot csb> <20130821174129 dot GE19750 at two dot firstfloor dot org>
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 having a general HTM fast path retry handling on
> > the C++ side.
> I don't see much point in trying to unify these fast paths for very
> different implementations with different properties. It would
> not surprise me if the highly tuned end result is different.
> It's kind of like trying to write a portable high performance memcpy().
I agree that highly tuned implementations might eventually be pretty
different from each other. Nonetheless, I'm currently not aware of
anybody volunteering to really work on highly tuned implementations, in
particular regarding the retry policies. Once we get there -- and it
would be great if somebody would work on that!, I'm completely fine with
separating those bits out. Until then, I think it's preferable to keep
things as unified as possible as long as this doesn't come with
unreasonable complexity or runtime overheads.