This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [trans-mem] rewrite transaction lowering

Richard Henderson wrote:
The lowering of transactions are now much more to my liking. It's a 5 step process, described in detail in a block comment at the beginning of gtm-low.c. The important functional changes are (1) we properly commit the transaction when we leave the region via an exception, and (2) we accurately describe the CFG, and the abnormal edges created by the longjmp used to restart or abort the transaction.

Thanks a lot Richard for getting so quickly into the GTM code. Martin and I are thrilled to see that some of our long-standing issues have been solved so nicely.

Still to do is rtl expansion of the TM_LOAD/STORE nodes, rewriting
creation of the transactional clones as real IPA pass, duplicating the transaction region without annotations as a fast-path when the transaction gets (re-)started in sequential mode.


We also expect much performance boost by movint into a real IPA pass. Being able to mark the read/write barriers with the proper VUSE and VDEF is known to seriously inhibit optimizations that would normally apply on the non-instrumented variant of a function (or outside a tm_atomic block).

We also expect many redundancies to disappear once the instrumentation (not only the checkpointing) will operate on SSA form, after PRE removes redundant load/store instructions.

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).

We have seen these problems occuring in real-world parallelization experiments, when extending the par-loops pass with automatic TM insertion for generalized reduction support. Andrea Marongiu from U. Bologna is investigating this issue, and any feedback or idea or benchmark motivating this approach would be very welcome.

What I generate is no longer compatible with TinySTM. It's closer to what I believe the final ABI should look like. At some point I'll either import some existing GPL STM library (TinySTM, unless someone has a better suggestion) or start a new one from scratch. We'll see...

I just notice one stupid thing that reminds me of some license problem we had with Graphite... TinySTM is GPLv2, not GPLv2+ :-( I guess the problem could be trivially solved by updating the license in this case, as the copyright holders are well identified. Yet TinySTM is not a very big piece of code, and it would indeed make sense to derive a GCC-specific STM from it. I don't see any urgency here, however.

Also, one emphasis of our GTM project is to help TM research (Martin Schindewolf is funded by the HiPEAC european research network, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]