On Tue, Nov 20, 2018 at 8:59 AM Eric Botcazou <ebotca...@adacore.com> wrote: > > > 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.
Taking into account that BB edges aren't scheduling barriers, I agree with [7]. > > 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. Ah yes. Thanks for the correction. However, I think that - according to the reintroduced duplicated comment - the blockage, reintroduced by DF merge should not be needed. I'll investigate this a bit and try to bootstrap/regtest a patch that removes reintroduced blockage. > 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). The testcase actually exposes -fschedule-insn problem with x86, so the test is not totaly artificial. The idea of removing the kludge for certain targets is tempting (the scheduler will be given some more freedom), but I agree that it should not be removed in stage-3. Thanks, Uros.
