[patch] generate dual code paths in transactions

[Aldy Hernandez <aldyh at redhat dot com>]

As originally discussed here...

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02648.html

...the goal is to generate dual code paths for transactions: one for the 
instrumented code path, and one without instrumentation.

In keeping with tradition, the implementation was nightmarish and our 
plan of attack changed mid-flight, various times.  It makes more sense 
to merge the patch in the link above with this one, and thus show the 
whole thing working.

Abnormal edges have been rewritten, things have been revamped, 
reorganized, and reconfused.  Hopefully there are enough comments and 
simplifications to make things clearer and cleaner.

This implements the feature request in PR/46480 which I will soon be 
closing.  Any problems with the implementation or further optimizations 
should be filed as separate PRs.

Torvald has corresponding library changes in his recently posted patch 
([Patch] libitm: add HTM fastpath), and I believe he has some 
preliminary encouraging numbers.

There are 2 distinct compiler failures, which look like missed 
optimizations which I will hopefully be tackling in stage2 (aka tomorrow).

FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ 
= lala.x\\[55\\]" 1
FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "lala.x\\[55\\] = 
tm_save" 1
FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ 
= lala" 1
FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "lala = tm_save" 1

And there is a runtime error, for which Richard has a patch he is 
testing in a more favorable time zone:

FAIL: libitm.c/cancel.c (internal compiler error)

I've since lost track of who did what, so this is a combined patch from 
rth and myself.  I must say, for all the hard work that went into this, 
it sure is a small patch :).

Look Jakub, I didn't even have to relocate to Samoa for this stage1!

Attachment: curr
Description: Text document