thr3ads.net - llvm dev - [llvm-dev] MachineSink optimization in code containing a setjmp [Oct 2015]

If this information is useful, please help other people find it:
Share via:

TB Schardl via llvm-dev

2015-Oct-13 20:29 UTC

[llvm-dev] MachineSink optimization in code containing a setjmp

Hello LLVM-dev,

I think I've found an issue with the MachineSink optimization on a program
that uses setjmp.  It looks like MachineSink will happily move a machine
instruction into a following machine basic block (not necessarily a
successor), even when that later block can be reached through a setjmp.
Here is some example debug output from llc that I'm seeing:

Sinking along critical edge.
Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31,
%EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
        into block BB#11:
    Predecessors according to CFG: BB#8 BB#10 BB#32
 ...
        EH_SjLj_Setup <BB#36>, <regmask>
    Successors according to CFG: BB#34 BB#36
Sinking along critical edge.
Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31,
%EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
        into block BB#35:
    Predecessors according to CFG: BB#34 BB#36
..
    Successors according to CFG: BB#12(12) BB#13(20)

In this case, it looks like MachineSink moves the ADD64rr instruction from
BB#4 into BB#26, which post-dominates both BB#25 and BB#27.  This movement
becomes a problem, I think, when the arguments of the moved instruction are
spilled onto the stack.  Here is the final assembly of the affected basic
blocks:

.LBB0_19
...
        movq    %rbp, -104(%rbp)
        movq    %rsp, -88(%rbp)
        movq    $.LBB0_42, 8(%r15)
        #EH_SjLj_Setup  .LBB0_42
# BB#20:
        movq    -176(%rbp), %rdi        # 8-byte Reload
        xorl    %ecx, %ecx
        jmp     .LBB0_21
.LBB0_42:
        movl    $1, %ecx
        movq    -176(%rbp), %rdi        # 8-byte Reload
.LBB0_21:
        movq    -168(%rbp), %rax        # 8-byte Reload
        addq    -144(%rbp), %rax        # 8-byte Folded Reload
        movq    %rax, -168(%rbp)        # 8-byte Spill

In my code, because of the setjmp, basic block .LBB0_21 ends up executing
twice, causing the addition to execute twice and produce an incorrect
result.

It seems like moving non-idempotent operations past a setjmp in this way
should be incorrect, because a corresponding longjmp can cause that
operation to execute twice.  Am I missing something in this reasoning?

Thank you in advance for your help.  I apologize for not having a small
test program handy.  The program in which I found this issue is somewhat
large and complex.

Cheers,
TB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/0bf192a6/attachment.html>

Daniel Berlin via llvm-dev

2015-Oct-13 21:04 UTC

head link

[llvm-dev] MachineSink optimization in code containing a setjmp

JUst to be clear: is the setjmp function marked returns_twice?


On Tue, Oct 13, 2015 at 1:29 PM, TB Schardl via llvm-dev
<llvm-dev at lists.llvm.org> wrote:> Hello LLVM-dev,
>
> I think I've found an issue with the MachineSink optimization on a
program
> that uses setjmp.  It looks like MachineSink will happily move a machine
> instruction into a following machine basic block (not necessarily a
> successor), even when that later block can be reached through a setjmp.
> Here is some example debug output from llc that I'm seeing:
>
> Sinking along critical edge.
> Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31,
> %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
>         into block BB#11:
>     Predecessors according to CFG: BB#8 BB#10 BB#32
>  ...
>         EH_SjLj_Setup <BB#36>, <regmask>
>     Successors according to CFG: BB#34 BB#36
> Sinking along critical edge.
> Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31,
> %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
>         into block BB#35:
>     Predecessors according to CFG: BB#34 BB#36
> ..
>     Successors according to CFG: BB#12(12) BB#13(20)
>
> In this case, it looks like MachineSink moves the ADD64rr instruction from
> BB#4 into BB#26, which post-dominates both BB#25 and BB#27.  This movement
> becomes a problem, I think, when the arguments of the moved instruction are
> spilled onto the stack.  Here is the final assembly of the affected basic
> blocks:
>
> .LBB0_19
> ...
>         movq    %rbp, -104(%rbp)
>         movq    %rsp, -88(%rbp)
>         movq    $.LBB0_42, 8(%r15)
>         #EH_SjLj_Setup  .LBB0_42
> # BB#20:
>         movq    -176(%rbp), %rdi        # 8-byte Reload
>         xorl    %ecx, %ecx
>         jmp     .LBB0_21
> .LBB0_42:
>         movl    $1, %ecx
>         movq    -176(%rbp), %rdi        # 8-byte Reload
> .LBB0_21:
>         movq    -168(%rbp), %rax        # 8-byte Reload
>         addq    -144(%rbp), %rax        # 8-byte Folded Reload
>         movq    %rax, -168(%rbp)        # 8-byte Spill
>
> In my code, because of the setjmp, basic block .LBB0_21 ends up executing
> twice, causing the addition to execute twice and produce an incorrect
> result.
>
> It seems like moving non-idempotent operations past a setjmp in this way
> should be incorrect, because a corresponding longjmp can cause that
> operation to execute twice.  Am I missing something in this reasoning?
>
> Thank you in advance for your help.  I apologize for not having a small
test
> program handy.  The program in which I found this issue is somewhat large
> and complex.
>
> Cheers,
> TB
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

TB Schardl via llvm-dev

2015-Oct-13 21:24 UTC

head link

[llvm-dev] MachineSink optimization in code containing a setjmp

We're using the llvm.eh.sjlj.setjmp() intrinsic.  From the IR, the
declaration of the intrinsic is only marked nounwind, but all calls to the
intrinsic are marked returns_twice.

TB

On Tue, Oct 13, 2015 at 5:04 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> JUst to be clear: is the setjmp function marked returns_twice?
>
>
> On Tue, Oct 13, 2015 at 1:29 PM, TB Schardl via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello LLVM-dev,
> >
> > I think I've found an issue with the MachineSink optimization on a
> program
> > that uses setjmp.  It looks like MachineSink will happily move a
machine
> > instruction into a following machine basic block (not necessarily a
> > successor), even when that later block can be reached through a
setjmp.
> > Here is some example debug output from llc that I'm seeing:
> >
> > Sinking along critical edge.
> > Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>,
%vreg31,
> > %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
> >         into block BB#11:
> >     Predecessors according to CFG: BB#8 BB#10 BB#32
> >  ...
> >         EH_SjLj_Setup <BB#36>, <regmask>
> >     Successors according to CFG: BB#34 BB#36
> > Sinking along critical edge.
> > Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>,
%vreg31,
> > %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31
> >         into block BB#35:
> >     Predecessors according to CFG: BB#34 BB#36
> > ..
> >     Successors according to CFG: BB#12(12) BB#13(20)
> >
> > In this case, it looks like MachineSink moves the ADD64rr instruction
> from
> > BB#4 into BB#26, which post-dominates both BB#25 and BB#27.  This
> movement
> > becomes a problem, I think, when the arguments of the moved
instruction
> are
> > spilled onto the stack.  Here is the final assembly of the affected
basic
> > blocks:
> >
> > .LBB0_19
> > ...
> >         movq    %rbp, -104(%rbp)
> >         movq    %rsp, -88(%rbp)
> >         movq    $.LBB0_42, 8(%r15)
> >         #EH_SjLj_Setup  .LBB0_42
> > # BB#20:
> >         movq    -176(%rbp), %rdi        # 8-byte Reload
> >         xorl    %ecx, %ecx
> >         jmp     .LBB0_21
> > .LBB0_42:
> >         movl    $1, %ecx
> >         movq    -176(%rbp), %rdi        # 8-byte Reload
> > .LBB0_21:
> >         movq    -168(%rbp), %rax        # 8-byte Reload
> >         addq    -144(%rbp), %rax        # 8-byte Folded Reload
> >         movq    %rax, -168(%rbp)        # 8-byte Spill
> >
> > In my code, because of the setjmp, basic block .LBB0_21 ends up
executing
> > twice, causing the addition to execute twice and produce an incorrect
> > result.
> >
> > It seems like moving non-idempotent operations past a setjmp in this
way
> > should be incorrect, because a corresponding longjmp can cause that
> > operation to execute twice.  Am I missing something in this reasoning?
> >
> > Thank you in advance for your help.  I apologize for not having a
small
> test
> > program handy.  The program in which I found this issue is somewhat
large
> > and complex.
> >
> > Cheers,
> > TB
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/cc70dbf4/attachment.html>

Maybe Matching Threads

Search for more apparently analagous threads

llvm dev - Oct 2015 - MachineSink optimization in code containing a setjmp

[llvm-dev] MachineSink optimization in code containing a setjmp

[llvm-dev] MachineSink optimization in code containing a setjmp

[llvm-dev] MachineSink optimization in code containing a setjmp

Maybe Matching Threads