On Wed, 2015-07-08 at 11:05 -0400, David Malcolm wrote:
> On Wed, 2015-07-08 at 10:21 -0400, David Malcolm wrote:
> > On Sat, 2015-07-04 at 16:58 +0100, Dibyendu Majumdar wrote:
> > > On 4 July 2015 at 14:20, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > > > On 4 July 2015 at 13:11, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > > >> Looks like in the failure case the code is being incorrectly
> > > >> optimized. I wonder if this is a manifestation of the get_address bug,
> > > >> perhaps the real fix will be better than the patch I am using. I will
> > > >> use the latest gcc 5 branch and see if that helps.
> > > >>
> > > >
> > > > Hi Dave,
> > > >
> > > > I am now using the latest gcc-5-branch from gcc github mirror.
> > > > Unfortunately the issue still persists.
> > > >
> > > > If set optimization level to 0 or 1, then it works ok, but at levels 2
> > > > or 3 the break occurs.
> > > >
> > > 
> > > Adding the -fno-strict-aliasing appears to resolve the issue with -O2
> > > and -O3 but with this enabled the benchmarks are degraded.
> > 
> > I've filed the bad code generation issue as:
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812
> > 
> > and I'm investigating it.
> 
> 
> Notes on investigation so far.
> 
> With the fixes here
>   https://gcc.gnu.org/ml/jit/2015-q3/msg00025.html
> and here:
>   https://gcc.gnu.org/ml/jit/2015-q3/msg00028.html
> the reproducer from
>  https://gcc.gnu.org/ml/jit/2015-q3/msg00012.html
> now correctly fails with:
>  error: gcc_jit_context_new_field: unknown size for field
> "errorJmp" (type: struct ravi_lua_longjmp)
> 
> Upon applying the equivalent of the fix from:
> https://github.com/dibyendumajumdar/ravi/commit/d65d2e68fbdcf211ed36deea05727f996ede8296
> to the generator you provided, gcc_jit_context_compile completes.
> 
> I don't know if it's generating bad code (given that I don't have Ravi
> itself running, just the reproducer).  However, I tried comparing the
> bug_rdump.txt and bug_rdump_ok.txt reproducers, and tried adding
> -fno-strict-aliasing to the former.
> 
> I turned on GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING and started comparing
> the dumpfiles.
> 
> The diffs stay easily comparable until fake.c.018t.ssa, when numbering
> differences between temporaries mean that a simple "diff" becomes
> unreadable.
> 
> So I wrote a tool to try to alleviate this:
>   https://github.com/davidmalcolm/gcc-dump-diff
> The tool tries to renumber temporaries in dumpfiles so that they are
> more consistent between runs, and then tries to do a textual diff of two
> dumpfiles.
> 
> (note that it might renumber labels also)

Yes, labels *were* being renumbered.  I've fixed that now.

> With this, the dumpfiles become comparable again.  I see that when
> rerunning the bug_rdump.txt reproducer, the first big difference between
> the with and without -fno-strict-aliasing case happens at 035t.fre1.
> 
> Note in the following how, without -fno-strict-aliasing, various
> statements and blocks are eliminated at 035t.fre1, which treats them as
> dead code.  In particular, it seems to have optimized away
> OP_TEST_do_jmp_5_0 and OP_TEST_do_skip_5_0 (if I'm reading things
> right).

It's OP_TEST_do_jmp_5_14, jmp_9_2 and OP_TEST_do_skip_5_15 that are
being optimized away by pass fre1 when -fno-strict-aliasing isn't
supplied.

I'm attaching a fixed diff, showing the correct label names.


> My hunch at this time is that this optimization is being too
> aggressive... for some reason.  I'll continue poking at this.

[snip]