Filed PR jit/66812 for the code generation issue

[Dibyendu Majumdar]

On 8 July 2015 at 18:46, David Malcolm <dmalcolm@redhat.com> wrote:
> I used gcc_jit_function_dump_to_dot to dump the CFG in GraphViz format;
> you can see the result here:
>  https://dmalcolm.fedorapeople.org/gcc/2015-07-08/rdump.png
> and with the printfs here:
>  https://dmalcolm.fedorapeople.org/gcc/2015-07-08/rdump_ok.png
>
> I see that both paths out of the "entry" block go through empty blocks
> and then into "jmp_5_1".
>
> A similar thing happens later with "jmp_9_2": both paths from the
> conditional lead through empty blocks to "jmp_12_3".
>
> Those pairs of empty blocks look odd.  Is the code correct?
>
> Looking at the body of "jmp_5_1", and annotating, I see:
>
> jmp_5_1:
>   (&L->ci->u.l.base[(int)1])->value_.b = (int)0;
>   (&L->ci->u.l.base[(int)1])->tt_ = (int)1;
>
>   comparison_0_11 = (&L->ci->u.l.base[(int)1])->tt_ == (int)0;
>      /* this must be true because of the 2nd assignment above */
>
>   comparison_0_12 = (&L->ci->u.l.base[(int)1])->tt_ == (int)1;
>      /* similarly this must be false */
>
>   comparison_0_13 = (&L->ci->u.l.base[(int)1])->value_.b == (int)0;
>      /* this must be true because of the 1st assignment above */
>
>   isfalse_0_10 = comparison_0_11 || comparison_0_12 && comparison_0_13;
>      /* hence we have:   true || false && true
>         and hence:       true  */
>
>   if (!(!(isfalse_0_10))) goto OP_TEST_do_jmp_5_14; else goto OP_TEST_do_skip_5_15;
>       /* hence this always takes the 1st path;
>          the 2nd path is indeed dead code */
>
> So it does in fact seem reasonable for the optimizer to optimize away
> OP_TEST_do_skip_5_15, and I think that once it does that, it merges
> OP_TEST_do_jmp_5_14 and jmp_9_2 into jmp_5_1, and can then do similar
> optimizations to the statements that were in jmp_9_2.
>
> So it seems that things I reported pass "fre1" as doing are reasonable.
>
> It seems that the optimizer is only able to assume the above values when
> strict aliasing is enabled, but it seems to be a reasonable
> optimization.  (I suspect that for some reason the presence of the
> printfs also is stopping this optimization; perhaps JIT doesn't know as
> much as the C frontend about the lack of side-effects of printf?)
>
> Is the code being supplied correct?  It's not clear to me what it's
> meant to be doing, but that CFG looks curious to me.  Maybe the input is
> incorrect, but it only turns into a problem when optimized?

I did check the generated code before for correctness but will do so
again, just to be sure. If the generated code was incorrect though the
test would fail under -O1 as well I would have thought.


Regards
Dibyendu