http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
At tmmark pass time, IPA inlining has already happened so we could conceivably
add code to the pass to remove nested transactions by accumulating all the BB's
in a nested candidate (nested transactions without a call to
__transaction_cancel), and manually removing the corresponding
GIMPLE_TRANSACTION and BUILT_IN_TM_COMMIT*'s.
The problem with this approach, however, is that the uninstrumented code path
has already been added (in pass_ipa_tm), prior to the IPA inlining pass, so the
CFG is a bit of a mess, with 2 transactions for each original transaction, as
well as with EDGE_TM_UNINSTRUMENTED edges linking things together. So to do
this properly, we should take care of removing one of the two paths entirely
(instrumented or uninstrumented), as well as removing all the
GIMPLE_TRANSACTION/BUILT_IN_TM_COMMIT*'s therein. [Note: It doesn't matter
which one, since tmmark has not run and there is no instrumentation in either
one. The paths are identical at this point.]
This isn't impossible, but tedious, and I wonder if it's worth doing for
unnecessary nested transactions appearing after IPA inlining. ??
Another approach would be to move the uninstrumenting code (which is currently
in pass_ipa_tm, which runs before IPA inlining) into its own actual IPA pass
(not this small_ipa_pass business) and run it right after IPA inlining. At
which point, right before doing the uninstrumentation edge thing, remove the
necessary GIMPLE_TRANSACTION/BUILT_IN_TM_COMMIT*'s, thus doing it before the
CFG becomes unnecessarily complex by the addition of the
instrumented/uninstrumented edges.
I'm not terribly fond of these approaches. Does anyone see a cleaner approach?
Am I missing something? Is it even worth doing?
