On Mon, Nov 19, 2018 at 11:42 PM Eric Botcazou <ebotca...@adacore.com> wrote: > > > The extra instruction is generated as a kludge in expand_function_end > > to prevent instructions that may trap to be scheduled into function > > epilogue. However, the same blockage is generated under exactly the > > same conditions earlier in the expand_function_end. The first blockage > > should prevent unwanted scheduling into the epilogue, so there is > > actually no need for the second one. > > But there are instructions emitted after the first blockage, aren't there?
Yes, but they don't generate exceptions. At least all memory accesses have /c flag. > Did you check the history of the code? I did. 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. 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. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14381 [2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=79265 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25176 [4] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=107871 [5] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=122626 [6] https://gcc.gnu.org/ml/gcc-patches/2007-02/msg01143.html [7] https://gcc.gnu.org/ml/gcc-patches/2007-02/msg01623.html [8] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/function.c?limit_changes=0&r1=125624&r2=125623&pathrev=125624 Uros.
