> The blockage was introduced as a fix for PR14381 [1] in r79265 [2]. > Later, the blockage was moved after return label as a fix for PR25176 > [3] in r107871 [4]. > > After that, r122626 [5] moves the blockage after the label for the > naked return from the function. Relevant posts from gcc-patches@ ML > are at [6], [7]. However, in the posts, there are no concrete > examples, how scheduler moves instructions from different BB around > blockage insn, the posts just show that there is a jump around > blockage when __builtin_return is used. I was under impression that > scheduler is unable to move instructions over BB boundaries.
The scheduler works on extended basic blocks. The [7] post gives a rather convincing explanation and there is a C++ testcase under PR rtl-opt/14381. > A mystery is the tree-ssa merge [8] that copies back the hunk, moved > in r122626 [5] to its original position. From this revision onwards, > we emit two blockages. It's the dataflow merge, not the tree-ssa merge. The additional blockage might be needed for DF. Given that the current PR is totally artificial, I think that we need to be quite conservative and only do something on mainline. And even there I'd be rather conservative and remove the kludge only for targets that emit unwind information in the epilogue (among which there is x86 I presume). -- Eric Botcazou
