Stuff to include in libgccjit 5.2

Stuff to include in libgccjit 5.2

[Dibyendu Majumdar]

Hi Dave,

Realise the deadline for 5.2 is close, but just wanted to let you know
that as I compile bytecodes I tend to run standard Lua test suite. I
am finding that the test suite fails at present. This could be due to
bugs in my code or bugs in libgccjit - it takes me some time to
isolate each issue into a small test case and then debug. In an ideal
world I would like to complete the implementation of all the major
bytecodes (at least to a level currently implemented in LLVM), and be
able to successfully run all tests. It would then be nice if I
discover any libgccjit bugs then the fixes for these to be included in
5.2. But not sure whether all this is possible before the 5.2
deadline.

Thanks and Regards

Dibyendu

Re: Stuff to include in libgccjit 5.2

[Dibyendu Majumdar]

On 30 June 2015 at 20:53, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> Hi Dave,
>
> Realise the deadline for 5.2 is close, but just wanted to let you know
> that as I compile bytecodes I tend to run standard Lua test suite. I
> am finding that the test suite fails at present. This could be due to
> bugs in my code or bugs in libgccjit - it takes me some time to
> isolate each issue into a small test case and then debug. In an ideal
> world I would like to complete the implementation of all the major
> bytecodes (at least to a level currently implemented in LLVM), and be
> able to successfully run all tests. It would then be nice if I
> discover any libgccjit bugs then the fixes for these to be included in
> 5.2. But not sure whether all this is possible before the 5.2
> deadline.
>

Pleased to report that the test suite is now working for the bytecodes
implemented so far. The bugs were all related to missing evaluations
of function call expressions. This is the most frequent mistake I am
making when porting LLVM code - in LLVM of course everything is
immediate - whereas in libgccjit one has to remember that an rvalue is
not evaluated unless it is used in a call or another expression.

I will try to implement as many op codes as I can over the weekend and
report back in case of issues.

Thanks and Regards

Dibyendu

Re: Stuff to include in libgccjit 5.2

[David Malcolm]

On Tue, 2015-06-30 at 22:15 +0100, Dibyendu Majumdar wrote:
> On 30 June 2015 at 20:53, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > Hi Dave,
> >
> > Realise the deadline for 5.2 is close, but just wanted to let you know
> > that as I compile bytecodes I tend to run standard Lua test suite. I
> > am finding that the test suite fails at present. This could be due to
> > bugs in my code or bugs in libgccjit - it takes me some time to
> > isolate each issue into a small test case and then debug. In an ideal
> > world I would like to complete the implementation of all the major
> > bytecodes (at least to a level currently implemented in LLVM), and be
> > able to successfully run all tests. It would then be nice if I
> > discover any libgccjit bugs then the fixes for these to be included in
> > 5.2. But not sure whether all this is possible before the 5.2
> > deadline.
> >
> 
> Pleased to report that the test suite is now working for the bytecodes
> implemented so far. The bugs were all related to missing evaluations
> of function call expressions. This is the most frequent mistake I am
> making when porting LLVM code - in LLVM of course everything is
> immediate - whereas in libgccjit one has to remember that an rvalue is
> not evaluated unless it is used in a call or another expression.

Would it be useful to have some kind of error/warning about unused
rvalues?  (this would almost certainly be for post-5.2 at this point
though)   Perhaps specifically for gcc_jit_context_new_call, that one
seems to be a "gotcha".

Something like:

  extern void
  gcc_jit_context_set_bool_check_for_unused_rvalues (gcc_jit_context *ctxt,
                                                     int bool_value);

issuing a hard error if enabled and there's an unused rvalue.

(defaulting to off?  or maybe to on, if all valid client code runs OK
with it on?)

> I will try to implement as many op codes as I can over the weekend and
> report back in case of issues.

FWIW, the deadline for the GCC 5.2 release candidate is Friday, and I
need to take Friday off from the computer for family stuff, so
effectively the only remaining jit things to go into 5.2 will be
whatever we get into trunk, and backport in the next two days.

I believe the two most important issues for Ravi are:

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546
("No way to disable check for unreachable blocks")
This is fixed in trunk, with a new entrypoint you'll need to call:
     gcc_jit_context_set_bool_allow_unreachable_blocks
I anticipate backporting this to gcc-5-branch tomorrow.


* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700
("Bogus gimplification of jit code using ptrs to functions", aka the
"Weird problem" thread)
I have a patch for this which I anticipate committing to trunk
and backporting to gcc-5-branch, both tomorrow.


Other issues affecting Ravi:

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
("jitted code should use -mtune=native")
Sadly I don't have a clean fix for this yet, and I don't anticipate
having one by the 5.2 deadline.  There's a hackish workaround for x86_64
attached to the bug.


* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628
('jit: Provide a way to add arbitrary options to the toplev "command
line"')
Fixed in trunk; I anticipate backporting the fix to gcc-5-branch
tomorrow.   BTW, note that I don't think you can inject "-mtune=native"
this way.


See also:
https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=66627&hide_resolved=0

plus various other patches I've already committed that I hope to
backport.

Did I miss anything important to Ravi?

Dave

Re: Stuff to include in libgccjit 5.2

[Dibyendu Majumdar]

On 1 July 2015 at 01:25, David Malcolm <dmalcolm@redhat.com> wrote:
> Would it be useful to have some kind of error/warning about unused
> rvalues?  (this would almost certainly be for post-5.2 at this point
> though)   Perhaps specifically for gcc_jit_context_new_call, that one
> seems to be a "gotcha".
>
> Something like:
>
>   extern void
>   gcc_jit_context_set_bool_check_for_unused_rvalues (gcc_jit_context *ctxt,
>                                                      int bool_value);
>
> issuing a hard error if enabled and there's an unused rvalue.
>
> (defaulting to off?  or maybe to on, if all valid client code runs OK
> with it on?)
>

Probably. I guess I will now be more careful about checking for this
so hopefully I won't make the same mistake. So you may want to wait
for other users' feedback before adding an API.

>> I will try to implement as many op codes as I can over the weekend and
>> report back in case of issues.
>
> FWIW, the deadline for the GCC 5.2 release candidate is Friday, and I
> need to take Friday off from the computer for family stuff, so
> effectively the only remaining jit things to go into 5.2 will be
> whatever we get into trunk, and backport in the next two days.
>

Ok

> I believe the two most important issues for Ravi are:
>
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546
> ("No way to disable check for unreachable blocks")
> This is fixed in trunk, with a new entrypoint you'll need to call:
>      gcc_jit_context_set_bool_allow_unreachable_blocks
> I anticipate backporting this to gcc-5-branch tomorrow.
>
>
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700
> ("Bogus gimplification of jit code using ptrs to functions", aka the
> "Weird problem" thread)
> I have a patch for this which I anticipate committing to trunk
> and backporting to gcc-5-branch, both tomorrow.
>

Yes these are the must haves. Rest are all nice to have and can wait.

>
> Other issues affecting Ravi:
>
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
> ("jitted code should use -mtune=native")
> Sadly I don't have a clean fix for this yet, and I don't anticipate
> having one by the 5.2 deadline.  There's a hackish workaround for x86_64
> attached to the bug.
>
>
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628
> ('jit: Provide a way to add arbitrary options to the toplev "command
> line"')
> Fixed in trunk; I anticipate backporting the fix to gcc-5-branch
> tomorrow.   BTW, note that I don't think you can inject "-mtune=native"
> this way.
>
>
> See also:
> https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=66627&hide_resolved=0
>
> plus various other patches I've already committed that I hope to
> backport.
>
> Did I miss anything important to Ravi?
>

No that's it so far.


Thanks and Regards
Dibyendu

Re: Stuff to include in libgccjit 5.2

[David Malcolm]

On Wed, 2015-07-01 at 07:49 +0100, Dibyendu Majumdar wrote:
> On 1 July 2015 at 01:25, David Malcolm <dmalcolm@redhat.com> wrote:
> > Would it be useful to have some kind of error/warning about unused
> > rvalues?  (this would almost certainly be for post-5.2 at this point
> > though)   Perhaps specifically for gcc_jit_context_new_call, that one
> > seems to be a "gotcha".
> >
> > Something like:
> >
> >   extern void
> >   gcc_jit_context_set_bool_check_for_unused_rvalues (gcc_jit_context *ctxt,
> >                                                      int bool_value);
> >
> > issuing a hard error if enabled and there's an unused rvalue.
> >
> > (defaulting to off?  or maybe to on, if all valid client code runs OK
> > with it on?)
> >
> 
> Probably. I guess I will now be more careful about checking for this
> so hopefully I won't make the same mistake. So you may want to wait
> for other users' feedback before adding an API.
> 
> >> I will try to implement as many op codes as I can over the weekend and
> >> report back in case of issues.
> >
> > FWIW, the deadline for the GCC 5.2 release candidate is Friday, and I
> > need to take Friday off from the computer for family stuff, so
> > effectively the only remaining jit things to go into 5.2 will be
> > whatever we get into trunk, and backport in the next two days.
> >
> 
> Ok
> 
> > I believe the two most important issues for Ravi are:
> >
> > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546
> > ("No way to disable check for unreachable blocks")
> > This is fixed in trunk, with a new entrypoint you'll need to call:
> >      gcc_jit_context_set_bool_allow_unreachable_blocks
> > I anticipate backporting this to gcc-5-branch tomorrow.

Done: backported in gcc-5-branch as r225254.

> >
> > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66700
> > ("Bogus gimplification of jit code using ptrs to functions", aka the
> > "Weird problem" thread)
> > I have a patch for this which I anticipate committing to trunk
> > and backporting to gcc-5-branch, both tomorrow.
> >

Done: committed to trunk as r225248 and to gcc-5-branch as r225258.

> Yes these are the must haves. Rest are all nice to have and can wait.

OK; thanks.  These will be in gcc 5.2, barring any unforeseen mess-ups.

> > Other issues affecting Ravi:
> >
> > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
> > ("jitted code should use -mtune=native")
> > Sadly I don't have a clean fix for this yet, and I don't anticipate
> > having one by the 5.2 deadline.  There's a hackish workaround for x86_64
> > attached to the bug.

Still unlikely to be fixed for 5.2, sorry.


> > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628
> > ('jit: Provide a way to add arbitrary options to the toplev "command
> > line"')
> > Fixed in trunk; I anticipate backporting the fix to gcc-5-branch
> > tomorrow.   BTW, note that I don't think you can inject "-mtune=native"
> > this way.

Done: backported to gcc-5-branch as r225253.


> > See also:
> > https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=66627&hide_resolved=0
> >
> > plus various other patches I've already committed that I hope to
> > backport.
> >
> > Did I miss anything important to Ravi?
> >
> 
> No that's it so far.

Thanks.  I believe gcc 5.2 will contain Ravi's "must-have" bug-fixes.

Dave