On Thu, Dec 19, 2013 at 5:04 PM, Aldy Hernandez <al...@redhat.com> wrote: > As discussed in the PR, we already remove nested transactions in the tmlower > stage, but inlining may add more nested transactions later. > > The problem with removing these nested transactions after proper IPA, is > that we'd either have to add another IPA pass later or remove the > problematic transactions much later in the .tmmark stage. Either of these > places will be after we have added the uninstrumented code path, so things > look a little messy CFG-wise (not impossible to do, but messy). > > What I've done in this patch is to fix the inliner cost model so that the > early inliner sees and inlines the transaction early on. This way, .tmipa > can see the inlined nested transaction before it adds the uninstrumented > code path, making everything simpler. Then it's just a matter of removing > the GIMPLE_TRANSACTION and associated commit. > > I'm still unsure whether the IPA inliner (not the early inliner) will add > other nested transactions, so we may have to do everything in .tmmark and > handle the dual code paths :(. Either way, this is a start.
Sure it will. At least with cross-unit inlining with LTO. You can of course simply disallow inlining a function that has transactions into a transaction when transactions are lowered already. Richard. > Also, is there anything I should check here, or is checking for > GTMA_HAVE_ABORT enough? > > + /* An inner transactions which has no explicit aborts can be > + folded into its outer transaction. */ > + unsigned int sub = gimple_transaction_subcode > (region->transaction_stmt); > + if (outer && !(sub & GTMA_HAVE_ABORT)) > > Tested on x86-64 Linux. > > How does this look?
