LTO inlining of transactional builtins

[Aldy Hernandez]

Hi gentlemen.

I am looking again at LTO + TM.  The goal is to be able to link with the 
implemented _ITM_* functions in libitm.a, and have them inlined into the 
transaction code when profitable.

To refresh everyone's memory, the original problem was two-fold:

a) If a user provides a builtin implementation to LTO, it is discarded, 
since by design LTO prefers builtins to user-provided versions of them. 
  In LTO, builtins are their own prevailing decl.  There is an 
enhancement request PR here:

	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997

b) LTO streaming happens before TMMARK.  Since the TMMARK pass is the 
one that instruments memory operations into __builtin_ITM_* calls, even 
if (a) was fixed, LTRANS would have nothing to inline.

Unfortunately, the tmmark pass can't be moved earlier, because the point 
is to delay its work so memory and loop optimizations can do its thing 
before memory operations are irreconcilably transformed into function calls.

FYI, the original thread was here:

	http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01258.html

Now unto my current woes... (I'm concentrating on problem (b) here).

My original thought of moving the LTO streaming point after tmmark under 
certain circumstances is a no go.  If at compile time we were to run 
tmmark and then stream LTO out, at link/lto time we will do: inline, 
ipa-tm, optimizations, tmmark.  Unfortunately, IPA-TM will add new TM 
clones with __builtin_ITM_* calls.  This would mean that new clones 
don't get TM calls inlined, while the lexical __atomic blocks do.

rth and I have been talking about re-running inlining after tmmark 
specifically for the TM builtins.

As you can imagine the pass manager isn't designed to run IPA passes 
after the regular optimization passes run, and I don't see a generic 
need for this apart from the TM problem-- although I could be wrong.

I tried playing with forcing another run of the early inliner after 
tmmark, since it is designed as a GIMPLE_PASS, but by 
pass_all_optimizations time, we have removed cgraph and gimple bodies. 
Seeing the amount of setup I have to do to re-run early inlining after 
the gimple optimizations have begun, perhaps I should steer my effort to 
running proper IPA inlining some time after tmmark.

Before I embark on more surgery, I would like your input.  I am 
entertaining the following two options:

a) Have tmmark set up IPA infrastructure for ipa_inline() to
run, and run it directly at the end of the pass (instead of through the 
pass manager).  Ugly, but localized.

b) Modify execute_pass_list() so subpasses can be IPA passes.  Set up 
appropriate infrastructure as in (a), and run this specialized IPA 
inline (or whatever subpasses we may add in the future).  This is 
converse to ipa_*summaries*() where we run subpasses that are local 
passes.  Generic, but I question whether anyone else will ever need this.

What do you think?  Am I nuts to even consider this?  Other ideas?

BTW, I still question whether even inlining will gain us much, since 
after tmmark there are few optimizations left to run (except RTL 
optimizations).  So I would guess that any gain from TM builtin inlining 
will be speed and any benefits RTL optimizations can give us. 
Still...I'm willing to play along a bit longer...

Thanks.
Aldy