Re: [PATCH, middle-end]: Fix PR 88070, ICE in create_pre_exit, at mode-switching.c:438

[Uros Bizjak <ubizjak@gmail.com>]

On Mon, Nov 19, 2018 at 11:42 PM Eric Botcazou <ebotcazou@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.