[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