lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Wed, 2004-11-10 at 22:58 +0000, Daniel Silverstone wrote:
> Hurrah; I get to put myself out of my own misery!

Or maybe not...

> With thanks to rici on #lua I have determined that of course if the last
> instruction is an OP_RETURN that doesn't mean that it is unconditionally
> executed.

But of course in this instance, fs->lasttarget == fs->pc

Also there's the case of the zero-length function where fs->pc == 0

So instead I propose:

  if ((fs->pc == 0) ||
      (GET_OPCODE(f->code[fs->pc-1]) != OP_RETURN) ||
      (fs->lasttarget == fs->pc))
    luaK_codeABC(fs, OP_RETURN, 0, 1, 0);  /* final return */

Which I believe passes all the following:

 1. empty function [adds OP_RETURN]
 2. last opcode is OP_RETURN and is conditional [adds OP_RETURN]
 3. last opcode is unconditional OP_RETURN [does not add]
 4. last opcode is anything but OP_RETURN [adds]

It is my belief that this condition is correct and valid.

It adds very little to the interpreter (a handful of bytes on x86) and
has the potential to save sizeof(Instruction)+sizeof(int) per Proto
which would otherwise end in an unconditional OP_RETURN

Of course this doesn't cover the following case:

if condition then
  return true
else
  return false
end

which of course still gains a fairly pointless OP_RETURN. I guess proper
basic-block analysis would be needed to get any further.

Aah well; I found this little detour informative and interesting and I
hope that some of you have too.

At least it'll all be archived now :-)

D.

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895