Stuff to include in libgccjit 5.2

David Malcolm dmalcolm@redhat.com
Thu Jan 1 00:00:00 GMT 2015


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



More information about the Jit mailing list