Re: Potentially merging the transactional-memory branch into mainline.

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> This is somewhat of a me-too message for the transactional-memory work. ?We
> would also like it to be considered for merging with mainline before the end
> of stage1.
>
> We have a kept a wiki here:
>
> http://gcc.gnu.org/wiki/TransactionalMemory
>
> What it is
> ==========
>
> From the wiki...
>
> Transactional memory is intended to make programming with threads simpler.
> As with databases, a transaction is a unit of work that either completes in
> its entirety or has no effect at all. Further, transactions are isolated
> from each other such that each transaction sees a consistent view of memory.
>
> Transactional memory comes in two forms: a Software Transactional Memory
> (STM) system uses locks or other standard atomic instructions to do its job.
> A Hardware Transactional Memory (HTM) system uses features of the cpu to
> implement the requirements of the transaction directly (e.g. Rock
> processor). Most HTM systems are best effort, which means that the
> transaction can fail for unrelated reasons. Thus almost all systems that
> incorporate HTM also have a STM component and are thus termed Hybrid
> Transactional Memory systems.
>
> The transactional memory system to be implemented in GCC provides single
> lock atomicity semantics. That is, a program behaves as if a single global
> lock guards each transaction.
>
> What it involves
> ================
>
> We have implemented the latest spec from the multi-vendor transactional
> memory group that includes AMD, Intel, Oracle, and others. ?The last
> official spec is what is in the wiki above, yet there are some minor changes
> to the keywords that are currently being finalized in the final document
> (but have already been agreed upon), and will be published shortly.
>
> It is my understanding (Torvald, correct me if I'm wrong), that the current
> implementation is what has been agreed to by the committee, and has been
> given a favorable nod by various members of the C++ standardization
> committee. ?Most importantly, the keywords are agreed upon.
>
> There are changes to the C and C++ front-end, and a software library
> (libitm) to go along with it. ?The library works on x86-64, x86-32, and
> Richard's favorite, Alpha :-). ?Porting to other architectures should be a
> straightforward affair.
>
> Status
> ======
>
> The current implementation runs the common TM benchmarks correctly, albeit
> there is still work to be done to improve performance.
>
> There are a handful of failed compiler tests on the included transactional
> memory testsuite (g*.dg/tm/*), but they are all missed optimizations, which
> we hope to have fixed after the merge.
>
> What's left
> ===========
>
> Torvald is working on some recent changes to noexcept, and we should have
> this working in a few days.
>
> I will be removing the cancel-throw construct which didn't make it in the
> final spec. ?I should have that done tomorrow.
>
> The final word
> ==============
> Seeing that a global maintainer has been lead on this for a while, I suspect
> there isn't much to review formally. ?I believe the only bits that Richard
> isn't directly responsible for are the C++ front-end changes.
>
> So what is the opinion/consensus on merging the branch? ?It would be nice to
> get this infrastructure in place as well so we can get people to start using
> it, and then we can work out any issues that arise.
>
> I have no idea how this happened, but apparently I'm on the hook for merging
> both the cxx-mem-model and this branch (if/when one/both get approved). ?If
> this gets approved, I'd prefer to get the cxx-mem-model branch merged first,
> and the transactional-memory branch later during the week. ?I will be
> partially available during the weekend, and definitely during next week.

Given that you only recently merged with trunk again are you really
sure this is a great
idea at this point in time?  Does the GCC 4.7 user community benefit from this
in any way (or rather how much percentage of it)?

Thus, please consider merging early during GCC 4.8 stage1 instead.

Thanks,
Richard.