[trans-mem] rewrite transaction lowering

Jakub Jelinek jakub@redhat.com
Fri Oct 24 08:50:00 GMT 2008


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



More information about the Gcc-patches mailing list