From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9679 invoked by alias); 24 Oct 2008 07:58:29 -0000 Received: (qmail 9670 invoked by uid 22791); 24 Oct 2008 07:58:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Oct 2008 07:57:42 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m9O7veMO012410; Fri, 24 Oct 2008 03:57:40 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m9O7vdlE005410; Fri, 24 Oct 2008 03:57:39 -0400 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.2/8.14.2/Submit) id m9O7wElv016470; Fri, 24 Oct 2008 09:58:14 +0200 Date: Fri, 24 Oct 2008 08:50:00 -0000 From: Jakub Jelinek To: Albert Cohen Cc: Richard Henderson , gcc-patches@gcc.gnu.org Subject: Re: [trans-mem] rewrite transaction lowering Message-ID: <20081024075814.GG14706@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <48F8F7D7.9020505@redhat.com> <4900F58B.2060006@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4900F58B.2060006@inria.fr> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01019.txt.bz2 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