On Tue, 2012-05-22 at 23:40 +0200, Peter Gavin wrote:
> Hi guys,
>
> So, I think I'm going to remove sibling call optimization from my gcc
> tree for now.
>
> I had some problems initially with getting the code generation for the
> non-delay slot version working with sibling calls, so I decided to try
> disabling them entirely, for both with and without the delay slot.
> When I did that, a few of the gcc test cases that failed for the
> regular delay slot version started passing. So I think the code that
> was there before wasn't quite right.
Hi Pete,
Sibcalls are the hard end of GCC work, and there are known issues
upstream - it was disabled in Fedora 15 GCC for example, which led to
one OR32 compile time regression failure (dealing with 10^6 nested
parentheses blows up the stack without sibcalls).
If you are interested, take a look at Mark Probst's diploma dissertation
on implementing tail-call optimization (TCO), which I believe is the
origin of the current GCC implementation.
http://www.complang.tuwien.ac.at/schani/diplarb.ps
> I know it's an optimization that can be useful under certain cases,
> but really my goal right now is getting GCC to pass the whole
> testsuite, and sibling calls add some complications to that. Plus,
> the mechanisms for generating sibling calls aren't exactly well
> documented in the GCC internals (there's a long-standing bug report
> about this) so it's going to be difficult to debug anyways. (And
> honestly, if you're relying on your C compiler to optimize
> sibling/tail calls, you're not really coding standard C.)
It is a very important optimization for some code, so a handful of
programs will just not work. I'm not sure why you think TCO is not
standards compliant. It does tend to flush out non standard-compliant
code though.
> Basically, now, I'm down to 4 failing testcases under
> gcc.c-torture/execute that I need to solve. There are a handful of
> others in other places. Once those are done, I can try putting sibling
> calls back in. Or actually, I think it would be more useful to try to
> spend my time adding PIC so we can get full-blown linux support
> working. And making sure C++ is working would be nice, too. But
> that's all future work :)
PIC is really ABI/assembler/library work, the GCC stuff I believe is
trivial. There are some notes on the Wiki regarding discussions about
GOT/PLT representation, since that part of the ABI is still empty in the
architecture manual.
http://opencores.org/or1k/OpenRISC_PIC
Could you update the Wiki with your latest test results
(http://opencores.org/or1k/Newlib_tool_chain_test_results#C_compiler_2).
I'll take a look at the 4 failing testcases. We may have hit the same
issue when we did GCC 4.5 and be able to share some experience.
What is the target-libstdc++-v3 regression like? That was the thing that
took us forever to get working for GCC 4.5.
> I just thought I'd drop a note in case someone really has an objection to
> this.
None from me. Keep up the good work.
Jeremy
--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: [email protected]
Web: www.embecosm.com
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
