[sdcc-devel] [ sdcc-Bugs-3293371 ] omit-frame-pointer still generates prolog

[SourceForge.net <no...@so...>]

Bugs item #3293371, was opened at 2011-04-26 23:38
Message generated for change (Comment added) made by u6c87
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: z80 port
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Ruthven (u6c87)
Assigned to: Nobody/Anonymous (nobody)
Summary: omit-frame-pointer still generates prolog

Initial Comment:
The following trivial example code:

int
func(int a)
{
        return (a * 2);
}

when compiled with "sdcc -mz80 --fomit-frame-pointer --no-peep -c omit_fp.c" generates this:

_func_start::
_func:
        push    ix
        ld      ix,#0
        add     ix,sp
;omit_fp.c:4: return (a * 2);
        ld      iy,#4
        add     iy,sp
        ld      l,0 (iy)
        ld      h,1 (iy)
        add     hl,hl
00101$:
        ret
_func_end::


The epilog (of "pop ix") is correctly omitted, but the prolog of push ix, etc... is still present. Thus, 8 redundant bytes per function are wasted (as ix is calculated but never referenced), and the saved ix is not popped, so the ret at 00101$ will jump to somewhere "random" based on the previous contents of ix.

Trying to run code produced like this produces strange results instantly (ranging from a "crash" to a coincidental loop round garbage in memory). However, as this seems to be such a fundamental problem with the option, I would guess that nobody actually uses it. Indeed, I only turned it on "for a laugh" to see how much larger the code would become. Thus it's by no means a high priority (as I don't intend to use it myself, but wanted to report the error).

Compiler used:
SDCC : z80 3.0.2 #6468 (Apr 26 2011) (Solaris i386)


----------------------------------------------------------------------

>Comment By: Brian Ruthven (u6c87)
Date: 2011-05-05 12:21

Message:
> Brian, you're wrong here in describing the use case. The Z80 uses IX as
> frame pointer and this CAN be used for other indexed actions, so it
could
> make sense to have this option.

What I meant was this:


, on x86, you can read directly from the %rsp+offset if you wanted to, so
you can dispense with setting up %rbp as the frame and use it for something
else. On Z80, you cannot do this with sp directly, hence use of the ix
register.



----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2011-05-05 11:13

Message:
> --fomit-frame-pointer is currently the only way to tell sdcc not to use
the iy register.

I assume you mean IX here.


optralloc gen.c:4105
	          if(!_G.omitFramePtr)

is half of the fix. But

gen.c:4116
	        emit2 ("!enterx", sym->stack);

also needs to be fixed IMHO with

          if (_G.omitFramePtr)
            emit2 ("!ldaspsp", -sym->stack);
          else
            emit2 ("!enterx", sym->stack);

As well as
gen.c:4119
	    emit2 ("!enter");

      if (!_G.omitFramePtr)
        emit2 ("!enter");

Then gen.c:2371 (aopGet)
	          else

should be

          else if (_G.omitFramePtr)
            {
              setupPair (PAIR_IX, aop, offset);
              dbuf_tprintf (&dbuf, "!*ixx", offset);
            }
          else

Then with these fixes many regression tests fail and the first one
(addsub) destroys HL in testAdd() for result += 0xab00;


Brian, you're wrong here in describing the use case. The Z80 uses IX as
frame pointer and this CAN be used for other indexed actions, so it could
make sense to have this option.

So, Philipp, shall I commit these changes even though it fixes only half
the problem?

----------------------------------------------------------------------

Comment By: Philipp Klaus Krause (spth)
Date: 2011-05-05 10:19

Message:
This bug seems to have been at least partially fixed in the optralloc
branch some time ago (at least I cannot reproduce it with a small example,
such as the one the OP gave).
However many (about one in twenty or so) regression tests fail when when
using --fomit-frame-pointer.

I remember that the z88dk folks were experimenting with using sdcc as
their underlying compiler some time ago. AFAIR they used
--fomit-frame-pointer and got some applications to work.

Philipp


----------------------------------------------------------------------

Comment By: Philipp Klaus Krause (spth)
Date: 2011-05-05 10:11

Message:
Sorry, but IMO we still need this. AFAIR it worked somehow not too long
ago.
--fomit-frame-pointer is currently the only way to tell sdcc not to use
the iy register. Unfortunately some OS designers have made the bad choice
of reserving ix for OS or interrupt routine use, thus applciations meant to
be run under these OS are not allowed to touch ix (it'S similar for iy,
that's why I introduced --reserve-regs-iy some time ago).

Philipp


----------------------------------------------------------------------

Comment By: Brian Ruthven (u6c87)
Date: 2011-05-05 09:53

Message:
>From my point of view it was academic interest.

Given the limited scope of this, and the severe brokenness on z80
(combined with the increase in both code size and execution time), I would
have to conclude that nobody is actually using it, and it's probably better
to simply remove it.

Having an "omit-frame-pointer" option would probably make sense on
architectures where there is a dedicated stack pointer register which can
be used for indexed operations (like x86 and SPARC) and thus omitting the
frame pointer can free up another register. This certainly isn't the case
on Z80 (I can't say for the other architectures that SDCC supports), so I'd
be happy just dropping the option completely. I can't believe anybody else
is actually using it given the broken code it generates!


----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2011-05-04 20:46

Message:
I made an attempt to fix this, but after the stack frame was fixed it
failed register allocation in the regression tests.

Next I looked where this option is actually used and it hardly seems to
be.
The hc08 port sets the flag but doesn't use it.
The pic16 port uses it to setup/restore the framepointer but not for
access to the stack frame.
Only the z80 uses it and that is severely broken.

Now my question is: is this option useful or only of academic interest? Or
in other words: are we going to try to fix this or is it better to just
remove it? In the latter case I will remove my local patches instead of
committing them.

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3293371&group_id=599