Hit a showstopper issue

[David Malcolm]

On Sun, 2015-06-14 at 21:00 +0100, Dibyendu Majumdar wrote:
> I have hit an issue that is a show stopper for me.
> 
> In Lua, redundant bytecodes are emitted that end up being unreachable
> blocks in the generated code. In LLVM these unreachable blocks are
> simply eliminated during optimization. But libgccjit is failing with
> an error.
> 
> Here is a minimal Lua function.
> 
> x=function() return; end
> 
> The generated Lua bytecode is this:
> 
> function <test.lua:1,1> (2 instructions at 0xad4840)
> 0 params, 2 slots, 0 upvalues, 0 locals, 0 constants, 0 functions
> 1 [1] RETURN   0 1
> 2 [1] RETURN   0 1
> constants (0) for 0xad4840:
> locals (0) for 0xad4840:
> upvalues (0) for 0xad4840:
> 
> As you can see there is a redundant RETURN bytecode.
> 
> The code I generate is this:
> 
> static int
> ravif1 (struct ravi_lua_State * L)
> {
>   struct ravi_TValue * base;
> 
> entry:
>   base = L->ci->u.l.base;
>   base = L->ci->u.l.base;
>   L->top = &base[(int)0];
>   if ((struct ravi_LClosure *)L->ci->func->p->sizep > (int)0) goto
> <UNNAMED BLOCK 0x2360800>; else goto <UNNAMED BLOCK 0x2360850>;
> 
> <UNNAMED BLOCK 0x2360800>:
>   (void)luaF_close (L, base);
>   goto <UNNAMED BLOCK 0x2360850>;
> 
> <UNNAMED BLOCK 0x2360850>:
>   (void)luaD_poscall (L, &base[(int)0]);
>   return (int)1;
> 
> <UNNAMED BLOCK 0x2360c00>:
>   base = L->ci->u.l.base;
>   L->top = &base[(int)0];
>   if ((struct ravi_LClosure *)L->ci->func->p->sizep > (int)0) goto
> <UNNAMED BLOCK 0x2360a60>; else goto <UNNAMED BLOCK 0x2361290>;
> 
> <UNNAMED BLOCK 0x2360a60>:
>   (void)luaF_close (L, base);
>   goto <UNNAMED BLOCK 0x2361290>;
> 
> <UNNAMED BLOCK 0x2361290>:
>   (void)luaD_poscall (L, &base[(int)0]);
>   return (int)1;
> }
> 
> When this is compiled the following errors occur:
> 
> libgccjit.so: error: unreachable block: <UNNAMED BLOCK 0xad5c40>
> libgccjit.so: error: unreachable block: <UNNAMED BLOCK 0xad5aa0>
> libgccjit.so: error: unreachable block: <UNNAMED BLOCK 0xad62d0>

The idea of this check was an attempt to be helpful, in that in other
bytecode compilers I've worked on, an unreachable block meant a bug in
the compiler, and the check has helped me track down bugs in those.

Clearly this check is unhelpful for Lua, so maybe we need an option to
disable it, something like:
  GCC_JIT_BOOL_OPTION_ERROR_ON_UNREACHABLE_BLOCKS
or somesuch.

A (nasty) workaround might be to generate something like this:

   if (0)
     goto block0;
   else if (0)
     goto block1;
   ...
   else if (0)
     goto blockN;
   else
     goto the real block;

which after optimization is equivalent to just:

   goto the real block;

but which fools the check into thinking all blocks0..N are reachable
(yes, I said it was nasty...)

Sorry about this.

Dave