[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Extraneous return
- From: Daniel Silverstone <dsilvers@...>
- Date: Wed, 10 Nov 2004 23:23:32 +0000
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