How to disable sibcall optimization?

How to disable sibcall optimization?

[Jan Hubicka]

Hi
While doing the usual benchmarking for new snapshot, I found that there are
important performance regresions in number of benchmarks (the overall results
are again comparable with 2.95).  While looking for the purpose I believe most
of those problems are caused by the sibcall code, that optimize flowgraph too
much and makes loop optimizer fail on even more loops than it does currently.
Now the loop fails in most cases on multiple entry points error.

It looks like there is no way to disable sibcalls easilly. Why? I think we
ought to have disabling flag for every such non-trivial transformation
for debugging purposes.

How far is the work on turning loop.c to use the new loop infrastructure?

Honza

Re: How to disable sibcall optimization?

[Richard Henderson]

On Wed, Mar 22, 2000 at 12:12:13PM +0100, Jan Hubicka wrote:
> It looks like there is no way to disable sibcalls easilly. Why?

No reason.


r~

Re: How to disable sibcall optimization?

[Jan Hubicka]

> On Wed, Mar 22, 2000 at 12:12:13PM +0100, Jan Hubicka wrote:
> > It looks like there is no way to disable sibcalls easilly. Why?
> 
> No reason.
I personally think that the performance regressions caused by the early
flowgraph construction and jump mentioned in this email are reason, but OK. I
will try to figure out what really happends w/o such switch.
It looks to me, that it is not too hard to implement it for my testing
purposes temporary now.
The slowdowns caused by latest snapshot are quite notable (at least
on Athlon/spec2000 approx 15%)

Honza
> 
> 
> r~

Re: How to disable sibcall optimization?

[Richard Henderson]

On Fri, Mar 24, 2000 at 04:00:46PM +0100, Jan Hubicka wrote:
> I personally think that the performance regressions caused by the early
> flowgraph construction and jump mentioned in this email are reason, but OK.
> I will try to figure out what really happends w/o such switch.

Eh?  We've crossed wires.  I said there was no reason we didn't
have the switch, which means that there's no reason not to add one.
Feel free to generate a patch.  ;-)

> The slowdowns caused by latest snapshot are quite notable (at least
> on Athlon/spec2000 approx 15%)

Yowza.  I wonder if simply removing the cleanup_cfg call
from optimize_sibling_and_tail_recursive_calls is enough
to fix things.


r~

Re: How to disable sibcall optimization?

[Jan Hubicka]

> Eh?  We've crossed wires.  I said there was no reason we didn't
> have the switch, which means that there's no reason not to add one.
> Feel free to generate a patch.  ;-)
Heh :) OK
I will probably do that.
> 
> > The slowdowns caused by latest snapshot are quite notable (at least
> > on Athlon/spec2000 approx 15%)
> 
> Yowza.  I wonder if simply removing the cleanup_cfg call
> from optimize_sibling_and_tail_recursive_calls is enough
> to fix things.
I didn't tested (and the machine is now about 70Km away turned off)
at friday I didn't understand the code enought to realize that disabling
may be so easy.
I've found some occurences of following constrcucts:
condjump label1
jmp label2
label1:
<some code>
label2:

And similar. It seems to me that flowgraph construction adds some notes
between the labels that makes imposible for jump1 to optimize even
such trivial examples. I am just trying to download the sources
here and continue in looking for real purpose.

But this don't seems to be only  purpose for those slowdowns.
Another one was the partial register stall introduced by my propagation
patch (this is not problem for Athlon), I have fix for this pending.

Honza
> 
> 
> r~

Re: How to disable sibcall optimization?

[Gerald Pfeifer]

On Wed, 22 Mar 2000, Jan Hubicka wrote:
> While doing the usual benchmarking for new snapshot, I found that
> there are important performance regresions in number of benchmarks
> (the overall results are again comparable with 2.95).

Just a small FYI, on C++ code of ours, current sources have been about
10-15% slower than GCC 2.95.2 on sparc-sun-solaris2.6.

I'll wait until the tree stabilizes again and then do more extensive
tests, but just in case someone is interested, I can provide source
as well as a nice benchmark suite for that program.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/