This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [trans-mem] rewrite transaction lowering
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Albert Cohen <Albert dot Cohen at inria dot fr>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 24 Oct 2008 09:58:14 +0200
- Subject: Re: [trans-mem] rewrite transaction lowering
- References: <48F8F7D7.9020505@redhat.com> <4900F58B.2060006@inria.fr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Oct 24, 2008 at 12:07:07AM +0200, Albert Cohen wrote:
> It may also help a lot to remove redundant barriers associated with
> already acquired read/write locks from previous ones (assuming a write
> lock subsumes a read lock, many redundancies occur, see Tabatabai and
> al's CGO'07 paper).
The question is how much we want to tighten GCC with the underlying TM
library (and possibly different configurations and/or runtime modes
thereof). E.g. for read after read or read after write if we know
the implementation is in-place-update, we can just use normal reads,
but if the implementation can be both in-place-update or write-buffering,
we can't do that.
> Also, one emphasis of our GTM project is to help TM research (Martin
> Schindewolf is funded by the HiPEAC european research network,
> http://www.hipeac.net). This means being able to retarget GTM to various
> TM runtimes, including hybrid ones (e.g., for Sun's HW, or for
> simulators). This emphasis should not inhibit a quickpath to a
> production-level support for TM in GCC, but interchangeability of the
> runtime is clearly important, as the existing runtimes are far from
> mature and many improvements could arise from third-party research and
> developments.
Here the question is whether we want the interchange to be done at the
compiler level or library level. Obviously for hybrid HW + SW approaches
the HW support needs to be in the compiler (just add the right insn patterns in
the target description and/or target hoos/builtins), for SW if we use
a sufficiently rich ABI (ideally a multi-vendor one), a STM library
shipped with GCC would of course support that ABI and for other TM
libraries you could just write a small interface library that would
translate the ABI calls to your TM library's ABI.
Jakub