[PATCH] PR jit/66812: Candidate fix for for the code generation issue, v1

[David Malcolm]

On Fri, 2015-07-10 at 01:39 +0100, Dibyendu Majumdar wrote:
> On 10 July 2015 at 01:14, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > On 10 July 2015 at 00:30, David Malcolm <dmalcolm@redhat.com> wrote:
> >> On Thu, 2015-07-09 at 23:20 +0100, Dibyendu Majumdar wrote:
> >>> On 9 July 2015 at 22:24, David Malcolm <dmalcolm@redhat.com> wrote:
> >>> > On Thu, 2015-07-09 at 17:15 -0400, David Malcolm wrote:
> >>> >> On Thu, 2015-07-09 at 17:06 -0400, David Malcolm wrote:
> >>> >>
> >>> >> (snip)
> >>> >>
> >>> >> > The fix will be to implement the LANG_HOOKS_GET_ALIAS_SET internal GCC
> >>> >> > API thus giving libgccjit some rules about aliasing.  Some options:
> >>> >> >
> >>> >> > (i) make it identical to C.
> >>> >> > (ii) give the client code some control over this
> >>> >> >
> >>> >> > My initial gut feeling is to go with (i).
> >>> >>
> >>> >> ...or possibly to do what the link-time optimizer does, which is to use
> >>> >> this internal API:
> >>> >>
> >>> >> /* Return the typed-based alias set for T, which may be an expression
> >>> >>    or a type.  Return -1 if we don't do anything special.  */
> >>> >>
> >>> >> alias_set_type
> >>> >> gimple_get_alias_set (tree t)
> >>> >>
> >>> >> which does almost all of what the C frontend does.  I'll try to cook up
> >>> >> a patch.
> >>> >
> >>> > Attached is a patch [1] which fixes the minimal reproducer I created,
> >>> > and the reproducer you sent.
> >>> >
> >>> > Does it work for you?
> >>> >
> >>>
> >>> I get this error when compiling:
> >>>
> >>> In file included from ../../gcc-5.1.0/gcc/jit/dummy-frontend.c:54:0:
> >>> ../../gcc-5.1.0/gcc/gimple.h: In function ‘void
> >>> gimple_call_set_fndecl(gimple, tree)’:
> >>> ../../gcc-5.1.0/gcc/gimple.h:2769:77: error:
> >>> ‘build_fold_addr_expr_loc’ was not declared in this scope
> >>>    gimple_set_op (gs, 1, build_fold_addr_expr_loc (gimple_location (gs), decl));
> >>>                                                                              ^
> >>> Am I missing something?
> >>
> >> The patch was for trunk, where GCC's internal headers have been
> >> reorganized, so we need different #includes for gcc-5-branch.
> >>
> >> Does the attached work?  (it compiles; I haven't tested it though)
> >>
> >
> > The isolated test works. Now running the full Lua test suite.
> 
> Tests worked

Good

> however performance degraded similar to when
> -fno-strict-aliasing is used.

Bother.  What kind of numbers are we talking about?