Slowdowns in code generated by GCC>=3.3

Slowdowns in code generated by GCC>=3.3

[Remko Troncon]

Hi,

I am a developer of a bytecode emulator for the Prolog language. With the
release of GCC-3.3, our emulator was slowed down by a factor of 3 on x86 with
-O3 turned on (we didn't measure other platforms; the optimization flag doesn't
seem to matter). We were hoping this was a temporary issue, but the situation
didn't improve in any of the newer releases :(
I don't know whether i should file this as a bug report, so i first ask
for advice her.

I'll try to explain on a high level what happens. If this isn't sufficient, 
i can try to give some code, but this will take me some time to isolate the
code. This is the situation:
- Since the program counter in our emulator is very crucial, we use the 
  'register' and 'asm ("bx")' hints.
- For each instruction in the bytecode, we store the address of the label
  of the code which has to be executed for the instruction. Therefore, 
  the program counter always contains points to an address of code to
  be executed, and after each instruction we do a 
	goto  **(void **)program_counter
Previous versions of GCC keep the program counter in ebx, and do a 
jmp *(%ebx) after the instructions (as expected). The newer GCCs seem
to unnecessarily move the program counter around between registers, and
don't do the jmp*(%ebx) after each instruction, but seem to jump to a
'common' piece of code doing this jump.

Looking at the changelog of gcc-3.3, i can only deduce this has to do with 
the new DFA scheduler, but of course i can not tell for sure.

I don't know if any of this information is useful, but we could use some 
pointers in places to look where things are going wrong in the code generation.
The factor 3 of slowdown is really a lot.

Does anyone have any ideas ?

thanks a lot,
Remko

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Wednesday 20 October 2004 14:34, Remko Troncon wrote:
> Hi,
>
> I am a developer of a bytecode emulator for the Prolog language. With the
> release of GCC-3.3, our emulator was slowed down by a factor of 3 on x86
> with -O3 turned on (we didn't measure other platforms; the optimization
> flag doesn't seem to matter).

Which x86 architecture variant?

> We were hoping this was a temporary issue,
> but the situation didn't improve in any of the newer releases :(
> I don't know whether i should file this as a bug report, so i first ask
> for advice here.

Filing a bug report is only going to be useful if you can report your
problem in a way such that we can reproduce it: test case, output of
"gcc -v", etc.  See http://gcc.gnu.org/bugs.html for the details ;-)


> I'll try to explain on a high level what happens. If this isn't sufficient,
> i can try to give some code, but this will take me some time to isolate the
> code. This is the situation:
> - Since the program counter in our emulator is very crucial, we use the
>   'register' and 'asm ("bx")' hints.

Is the program counter a global variable, or local?  And if you remove
those hints, does that make your code worse?
I would actually expect it to improve if you remove those hints.  x86
is a register starved architecture, and as the documentation mentions:

  "Defining such a register variable does not reserve the register; it
remains available for other uses in places where flow control determines
the variable's value is not live.  However, these registers are made
unavailable for use in the reload pass; excessive use of this feature
leaves the compiler too few available registers to compile certain
functions."
(see "info gcc", look for "Explicit Reg Vars")

For an architecture with basically only 6 registers, taking up just one
is probably "Excessive use" already.


> - For each instruction in the bytecode, we store the address of the label
>   of the code which has to be executed for the instruction. Therefore,
>   the program counter always contains points to an address of code to
>   be executed, and after each instruction we do a
> 	goto  **(void **)program_counter
> Previous versions of GCC keep the program counter in ebx, and do a
> jmp *(%ebx) after the instructions (as expected). The newer GCCs seem
> to unnecessarily move the program counter around between registers, and
> don't do the jmp*(%ebx) after each instruction, but seem to jump to a
> 'common' piece of code doing this jump.

Yes.  Indirect jumps are incredibly expensive at compile time, so what
the compiler does is "factor" the computed jump, i.e. given,

  goto *x;
  [ ... ]

  goto *x;
  [ ... ]

  goto *x;
  [ ... ]


the compiler factors the computed jumps results in the following code
sequence which has a much simpler control flow graph:

  goto y;
  [ ... ]

  goto y;
  [ ... ]

  goto y;
  [ ... ]

y:
  goto *x;

The compiler is supposed to unfactor this in the basic block reordering
pass, perhaps that is not happening for your code for some reason.


> Looking at the changelog of gcc-3.3, i can only deduce this has to do with
> the new DFA scheduler, but of course i can not tell for sure.

I can tell almost for sure that this is not the problem.  In GCC 3.3,
only the pentium has a DFA scheduler description, all other architecture
variants still use the old scheduler.  Besides, scheduling on i386 is a
local list scheduling and your problem seems to be control flow related.

> I don't know if any of this information is useful, but we could use some
> pointers in places to look where things are going wrong in the code
> generation. The factor 3 of slowdown is really a lot.

I would first try to remove that "register ... asm (...)" junk, and try
to optimize for something more advanced than i386 (which is the default
x86 architecture, see the manual, -march=*).  If that does not help,
please file a bug report including a test case as explained on bugs.html.

Gr.
Steven

Re: Slowdowns in code generated by GCC>=3.3

[Remko Troncon]

Hi,

> Which x86 architecture variant?

I measured in on a Pentium 4.

> Filing a bug report is only going to be useful if you can report your
> problem in a way such that we can reproduce it: test case, output of
> "gcc -v", etc.  See http://gcc.gnu.org/bugs.html for the details ;-)

Okay, but then i'll have to reduce the 7000 lines of code in the crucial
file to something smaller ;)

> Is the program counter a global variable, or local? 

It's local.

>  And if you remove those hints, does that make your code worse?  

Removing 'register ... asm(bx)' makes it a bit worse. Removing only
'asm(bx)' makes it worser than that. Although the difference in time is
not very big.

> Yes.  Indirect jumps are incredibly expensive at compile time, so what
> the compiler does is "factor" the computed jump, i.e. given,

This is indeed what happens.

> I can tell almost for sure that this is not the problem.  In GCC 3.3,
> only the pentium has a DFA scheduler description, all other
> architecture variants still use the old scheduler. 

Okay. It just seemed like the only change looking at the changelog, but
it doesn't sound like it has anything to do with it indeed. I just
didn't know exactly what it was.

> try to optimize for something more advanced than i386 (which is the
> default x86 architecture, see the manual, -march=*). 

I tried it with -march=pentium4 this time. Strangely enough, this makes
matters even worse.

thanks,
Remko

Re: Slowdowns in code generated by GCC>=3.3

[Richard Guenther]

On Wed, 20 Oct 2004 15:19:14 +0200, Remko Troncon
<remko.troncon@cs.kuleuven.ac.be> wrote:
> Hi,
> 
> > Which x86 architecture variant?
> 
> I measured in on a Pentium 4.
> 
> > Filing a bug report is only going to be useful if you can report your
> > problem in a way such that we can reproduce it: test case, output of
> > "gcc -v", etc.  See http://gcc.gnu.org/bugs.html for the details ;-)
> 
> Okay, but then i'll have to reduce the 7000 lines of code in the crucial
> file to something smaller ;)

This looks similar to PR15242 and related bugs.

Richard.

Re: Slowdowns in code generated by GCC>=3.3

[Ranjit Mathew]

Remko Troncon wrote:
> 
> I am a developer of a bytecode emulator for the Prolog language. With the
> release of GCC-3.3, our emulator was slowed down by a factor of 3 on x86 with
> -O3 turned on (we didn't measure other platforms; the optimization flag doesn't
> seem to matter). We were hoping this was a temporary issue, but the situation
> didn't improve in any of the newer releases :(

FWIW, there have been other grumblings about newer GCC
versions slowing down interpreter-like code:

http://article.gmane.org/gmane.comp.java.vm.sablevm.devel/1247

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Wednesday 20 October 2004 15:26, Richard Guenther wrote:
> This looks similar to PR15242 and related bugs.

It certainly does, thanks!

Let's see if we can wiggle it into mainline if
it fixes the problem...

Gr.
Steven

Re: Slowdowns in code generated by GCC>=3.3

[Remko Troncon]

> This looks similar to PR15242 and related bugs.

It sure does. However, I tried applying the patch to GCC-CVS, and
recompiled with -O3, but that didn't do anything to my performance :(

cheers,
Remko

Re: Slowdowns in code generated by GCC>=3.3

[Richard Guenther]

On Wed, 20 Oct 2004 16:25:16 +0200, Remko Troncon
<remko.troncon@cs.kuleuven.ac.be> wrote:
> > This looks similar to PR15242 and related bugs.
> 
> It sure does. However, I tried applying the patch to GCC-CVS, and
> recompiled with -O3, but that didn't do anything to my performance :(

I guess you need to specify -fno-crossjumping or -fno-reorder-blocks
(or both) to make it work.  See the patch chunk changing passes.c which
checks for !flag_crossjumping before doing the optimization.

Richard.

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Wednesday 20 October 2004 16:25, Remko Troncon wrote:
> > This looks similar to PR15242 and related bugs.
>
> It sure does. However, I tried applying the patch to GCC-CVS, and
> recompiled with -O3, but that didn't do anything to my performance :(

Probably because it happens too late and you're still killed by
register pressure, or does not actually change anything at all
for your test case (did you look to see if the computed jump was
un-factored?).  Try -fno-crossjumping.

Gr.
Steven

Re: Slowdowns in code generated by GCC>=3.3

[Mike Stump]

On Oct 20, 2004, at 5:34 AM, Remko Troncon wrote:
> With the release of GCC-3.3, our emulator was slowed down by a factor 
> of 3 on x86

Another thought, you can binary search the compiler sources from cvs, 
compiling your application at each instance to determine the patch that 
went in that regressed performance for you.

Re: Slowdowns in code generated by GCC>=3.3

[Remko Troncon]

Hi again,

> Another thought, you can binary search the compiler sources from cvs, 
> compiling your application at each instance to determine the patch that 
> went in that regressed performance for you.

I did a search through GCC CVS to find out which patch caused our factor
3 slowdown. Apparently, it is the patch with this ChangeLog entry:

2003-02-15  Richard Henderson  <rth@redhat.com>
        * bb-reorder.c (find_traces_1_round): Don't connect easy to copy
        successors with multiple predecessors.
        (connect_traces): Try harder to copy traces of length 1.
        * function.h (struct function): Add computed_goto_common_label,
        computed_goto_common_reg.
        * function.c (free_after_compilation): Zap them.
        * stmt.c (expand_computed_goto): Use them to produce one 
        indirect branch per function.

I tried patching the files one by one (in the order above, as i assumed the
problem was in stmt.c and that that file depended on function.*), and indeed,
once the 'stmt.c' is patched, the slowdown occurs.

Can something be done about this ?

thanks,
Remko

Re: Slowdowns in code generated by GCC>=3.3

[Mike Stump]

On Oct 23, 2004, at 5:40 AM, Remko Troncon wrote:
>> Another thought, you can binary search the compiler sources from cvs,
>> compiling your application at each instance to determine the patch 
>> that
>> went in that regressed performance for you.
>
> I did a search through GCC CVS to find out which patch caused our 
> factor
> 3 slowdown. Apparently, it is the patch with this ChangeLog entry:
>
> 2003-02-15  Richard Henderson  <rth@redhat.com>
>         * bb-reorder.c (find_traces_1_round): Don't connect easy to 
> copy
>         successors with multiple predecessors.
>         (connect_traces): Try harder to copy traces of length 1.
>         * function.h (struct function): Add computed_goto_common_label,
>         computed_goto_common_reg.
>         * function.c (free_after_compilation): Zap them.
>         * stmt.c (expand_computed_goto): Use them to produce one
>         indirect branch per function.

Wait, we're not done yet, that is just the first step.  The next step 
is to find an instance of changed code generation...  It would help if 
you gperf or gcov your code, and then find a hot instance of the code 
that changed.  gcc -save-temps can be used to preserve the preprocessed 
source code and the assembly.

 From there, if you can, trim down the extraneous code from the .i/.ii 
file and then submit that file as a bug report, with the flags, then 
generated .s before and after, and the net effect of the change (3x 
application slowdown) and the fact it is a regression and a pointer to 
the above changelog entry and the timings you get with and without 
that.

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Tuesday 26 October 2004 20:57, Mike Stump wrote:
> On Oct 23, 2004, at 5:40 AM, Remko Troncon wrote:
> >> Another thought, you can binary search the compiler sources from cvs,
> >> compiling your application at each instance to determine the patch
> >> that
> >> went in that regressed performance for you.
> >
> > I did a search through GCC CVS to find out which patch caused our
> > factor
> > 3 slowdown. Apparently, it is the patch with this ChangeLog entry:
> >
> > 2003-02-15  Richard Henderson  <rth@redhat.com>
> >         * bb-reorder.c (find_traces_1_round): Don't connect easy to
> > copy
> >         successors with multiple predecessors.
> >         (connect_traces): Try harder to copy traces of length 1.
> >         * function.h (struct function): Add computed_goto_common_label,
> >         computed_goto_common_reg.
> >         * function.c (free_after_compilation): Zap them.
> >         * stmt.c (expand_computed_goto): Use them to produce one
> >         indirect branch per function.
>
> Wait, we're not done yet, that is just the first step.  The next step
> is to find an instance of changed code generation...  It would help if
> you gperf or gcov your code, and then find a hot instance of the code
> that changed.  gcc -save-temps can be used to preserve the preprocessed
> source code and the assembly.
>
>  From there, if you can, trim down the extraneous code from the .i/.ii
> file and then submit that file as a bug report, with the flags, then
> generated .s before and after, and the net effect of the change (3x
> application slowdown) and the fact it is a regression and a pointer to
> the above changelog entry and the timings you get with and without
> that.

I already know exactly what the problem is.
In fact I mentioned it even before Remko confirmed that this patch is
causing his problem.

The patch makes us "factor" computed jumps.  From cfg.texi:

@smallexample
  goto *x;
  [ ... ]

  goto *x;
  [ ... ]

  goto *x;
  [ ... ]
@end smallexample

@noindent
factoring the computed jumps results in the following code sequence
which has a much simpler flow graph:

@smallexample
  goto y;
  [ ... ]

  goto y;
  [ ... ]

  goto y;
  [ ... ]

y:
  goto *x;
@end smallexample


Now, the problem is that gcse and crossjumping may move code in the
block with the factored computed jump, so when we later try to undo
the factoring, we think it is too expensive to do that.  We end up
with lots and lots of jumps to a single computed jump that is very
difficult to predict.
To make things even worse, the expressions gcse moves out increase
register pressure by just enough to make us spill too much on ix86.
For dProlog this caused a code size increase of ~60% for the (large)
function with the computed jump.

In rth's patch, bb-reorder is supposed to try harder to connect short
traces and duplicate them.  This apparently doesn't work, so Josef
Zlomek posted his patch that is linked to from the audit trail of
PR15242.
That patch fails, we clear current_function_has_computed_jump so we
never run the unfactoring.
Fixing that uncovers the problem with gcse and crossjumping, making
the unfactoring too expensive.
GCSE is a bigger problem (it's quite unlikely that crossjumping can
merge tails for typical code with computed jumps), so I suggest we
simply disable GCSE completely if there are computed jumps in some
function.  GCSE doesn't buy us much anyway for such code.

A patch I posted to Remko fixes his problem if he disables gcse and
crossjumping by hand.  I'm working on cleaning up that patch now so
that it is acceptable for mainline.  The most important problem is
current_function_has_computed_jump.  I plan to patch tree-cfg.c to
clean up computed jumps at the tree level, and let emit_indirect_jump
set current_function_has_computed_jump.  When it is set, we never
clear it after that.  This only affects sched-rgn in the unlikely
case that we'd clean up a computed jump at the RTL level.
The rest is just Josef's patch, revamped.

I hope to find time to finish the patch later this week.

Gr.
Steven

Re: Slowdowns in code generated by GCC>=3.3

[Pablo Mejia]

    Steven> Now, the problem is that gcse and crossjumping may move
    Steven> code in the block with the factored computed jump, so when
    Steven> we later try to undo the factoring, we think it is too
    Steven> expensive to do that.  We end up with lots and lots of
    Steven> jumps to a single computed jump that is very difficult to
    Steven> predict.

I just lurk on this list, so feel free to ignore this comment...

Perhaps it would be possible to mark the block with the factored
computed jump in some way.  Any pass which tries to do code motion, or
other problematic optimizations, could check that note and inhibit
code motion into the block.  That would preserve the block with the
factored computed jump so it can be un-factored later.  Perhaps then
it wouldn't be necessary to disable gcse in functions with computed
jumps.

Pablo

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Tuesday 26 October 2004 22:09, Pablo Mejia wrote:
>     Steven> Now, the problem is that gcse and crossjumping may move
>     Steven> code in the block with the factored computed jump, so when
>     Steven> we later try to undo the factoring, we think it is too
>     Steven> expensive to do that.  We end up with lots and lots of
>     Steven> jumps to a single computed jump that is very difficult to
>     Steven> predict.
>
> I just lurk on this list, so feel free to ignore this comment...
>
> Perhaps it would be possible to mark the block with the factored
> computed jump in some way.

It is cumbersome to maintain such a marking.  I tried it at
first but it's hard to not lose the mark, and it's harder to
change all passes to be aware of such a block.

Gr.
Steven

Re: Slowdowns in code generated by GCC>=3.3

[Giovanni Bajo]

Steven Bosscher wrote:

>>>> OK, then PR 15242 is *NOT* the problem reported by the original
>>>> poster of this thread, because he *does* have a regression when
>>>> compiling his code with 3.3.
>>>
>>> If 'regression' includes performance decrease, then indeed.
>>
>> Can you please file a bug report about this then, if you hadn't
>> already? CC me on the bug report please.
>
> *sigh*
> /me points at thread which mentions PR15242

/me points at the quoted text.

15242 is not a regression, the user is seeing a regression since 3.3. So either
you should mark 15242 as a regression (which I am told it would be incorrect),
or 15242, if related, does not capture the essence of the regression, which
appears (or is unconvered - it does not matter) only for versions above 3.3.

Giovanni Bajo

Re: Slowdowns in code generated by GCC>=3.3

[Steven Bosscher]

On Wednesday 27 October 2004 18:26, Giovanni Bajo wrote:
> Remko Troncon wrote:
> >> OK, then PR 15242 is *NOT* the problem reported by the original
> >> poster of this thread, because he *does* have a regression when
> >> compiling his code with 3.3.
> >
> > If 'regression' includes performance decrease, then indeed.
>
> Can you please file a bug report about this then, if you hadn't already? CC
> me on the bug report please.

*sigh*
/me points at thread which mentions PR15242

Re: Slowdowns in code generated by GCC>=3.3

[Giovanni Bajo]

Remko Troncon wrote:

>> OK, then PR 15242 is *NOT* the problem reported by the original
>> poster of this thread, because he *does* have a regression when
>> compiling his code with 3.3.
>
> If 'regression' includes performance decrease, then indeed.

Can you please file a bug report about this then, if you hadn't already? CC me
on the bug report please.

Giovanni Bajo

Re: Slowdowns in code generated by GCC>=3.3

[Joe Buck]

On Wed, Oct 20, 2004 at 11:22:10PM +0200, Remko Troncon wrote:
> > OK, then PR 15242 is *NOT* the problem reported by the original poster of
> > this thread, because he *does* have a regression when compiling his code
> > with 3.3.
> 
> If 'regression' includes performance decrease, then indeed.

A 3x performance decrease on a production program is most certainly a
regression.

Re: Slowdowns in code generated by GCC>=3.3

[Scott Robert Ladd]

Remko Troncon wrote:
> If 'regression' includes performance decrease, then indeed.
> 
> I tried playing with the -fno-crossjumping or -fno-reorder-blocks flags,
> but no change in performance. I didn't look at the generated code
> closely yet, because the code looked quite different than before, so i
> couldn't immediately if the jump was still factored out. It did look
> like the code was a lot more complex than with older GCCs, but I'll have
> to look at it closer tomorrow.

I'm not certain if this will help, and I don't know the nature of your 
program.

If you can isolate the offending code in a small, short-run example, you 
could run it through my Acovea program to analyze for pessimistic 
options. That might give us a clearer idea of what is causing the problem.

	http://www.coyotegulch.com/products/acovea/index.html

If this isn't something you want or can do, I'd be interested is anyone 
can come up with a short example that I could run through Acovea over 
the weekend.

-- 
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Re: Slowdowns in code generated by GCC>=3.3

[Remko Troncon]

> OK, then PR 15242 is *NOT* the problem reported by the original poster of
> this thread, because he *does* have a regression when compiling his code
> with 3.3.

If 'regression' includes performance decrease, then indeed.

I tried playing with the -fno-crossjumping or -fno-reorder-blocks flags,
but no change in performance. I didn't look at the generated code
closely yet, because the code looked quite different than before, so i
couldn't immediately if the jump was still factored out. It did look
like the code was a lot more complex than with older GCCs, but I'll have
to look at it closer tomorrow.

cheers,
Remko

Re: Slowdowns in code generated by GCC>=3.3

[Giovanni Bajo]

Andrew Pinski wrote:

>> We accept only bugfixes for regression on release branches, and this
>> PR is
>> not marked as a regression, right now. Given the subject of this
>> thread,
>> this could be a mistake on our side. Can anybody confirm that the
>> problem in
>> PR 15242 is a regression?
>
> This is not a regression see PR 8092 which talks about why this is not
> really a regression or a defect really.

OK, then PR 15242 is *NOT* the problem reported by the original poster of
this thread, because he *does* have a regression when compiling his code
with 3.3.

Giovanni Bajo

Re: Slowdowns in code generated by GCC>=3.3

[Andrew Pinski]

On Oct 20, 2004, at 4:14 PM, Giovanni Bajo wrote:

> Földy Lajos wrote:
>
>> Is there a chance, that the patch for PR15242 (if available) will go 
>> into
>> 3.4.3?
>
> We accept only bugfixes for regression on release branches, and this 
> PR is
> not marked as a regression, right now. Given the subject of this 
> thread,
> this could be a mistake on our side. Can anybody confirm that the 
> problem in
> PR 15242 is a regression?

This is not a regression see PR 8092 which talks about why this is not
really a regression or a defect really.

-- Pinski

Re: Slowdowns in code generated by GCC>=3.3

[Giovanni Bajo]

FĂśldy Lajos wrote:

> Is there a chance, that the patch for PR15242 (if available) will go into
> 3.4.3?

We accept only bugfixes for regression on release branches, and this PR is
not marked as a regression, right now. Given the subject of this thread,
this could be a mistake on our side. Can anybody confirm that the problem in
PR 15242 is a regression?

Giovanni Bajo

Re: Slowdowns in code generated by GCC>=3.3

[Zack Weinberg]

Peter Barada <peter@the-baradas.com> writes:

> Wouldn't it be better to make the compiler not do
> tail-merging/crossjumping unless the savings makes it wortwhile;
> i.e. don't do the jump to save less than N instructions(where in
> this case, it actaully *increases* the instruction count by one)?

I don't think you understand the problem.  The control flow graph
generated from the original code contains a very large number of basic
blocks each of which begins and ends with an abnormal edge.  The early
phases of optimization go into a very bad performance regime when
faced with such a control flow graph -- we're talking hours to compile
one function.

The tail merge in this case is done in spite of its making the
generated code worse; its sole function is to get the early optimizers
out of the bad performance regime.  It's *supposed* to be undone at
the end.  The bug is that that isn't happening.

(An alternative would be to detect the problem basic block structure
and disable the optimizations that can't handle it; if I remember
correctly which those are, they are unlikely to do anything useful on
such a function anyway.)

In any case, we're definitely in patches-are-welcome mode with regard
to getting this fixed.

zw

Re: Slowdowns in code generated by GCC>=3.3

[Peter Barada]

>> 
>> Nothing stops GCC from folding that asm into the common-ized jump
>> block.
>> 
>> zw
>> 
>
>I see.
>
>So the practical solution is 
>
>- generate asm listing
>- identify appropriate jumps, eg:
>
>        ...
>        movl    8(%ecx), %eax
>        jmp     .Lxxxxx
>	...
>.Lxxxxx:
>        jmp     *%eax
>
>- change "jmp .Lxxxxx" to "jmp *%eax" with your favorite text editor
>- compile the asm source

Wouldn't it be better to make the compiler not do
tail-merging/crossjumping unless the savings makes it
wortwhile; i.e. don't do the jump to save less than N
instructions(where in this case, it actaully *increases* the
instruction count by one)?

-- 
Peter Barada
peter@the-baradas.com

Re: Slowdowns in code generated by GCC>=3.3

[Zack Weinberg]

Földy Lajos <foldy@rmki.kfki.hu> writes:

> Is there a chance, that the patch for PR15242 (if available) will go
> into 3.4.3?

I can't speak to that.  From the discussion, it sounds like the bug
hasn't yet been fixed.

zw

Re: Slowdowns in code generated by GCC>=3.3

[Földy Lajos]

On Wed, 20 Oct 2004, Zack Weinberg wrote:

> Földy Lajos <foldy@rmki.kfki.hu> writes:
> 
> > and what about adding the real goto (which will be never executed, but
> > gcc will have "almost real" control flow):
> >
> >  	__asm__("jmp *%0" : : "a" (pc));
> > 	goto *pc;
> 
> Nothing stops GCC from folding that asm into the common-ized jump
> block.
> 
> zw
> 

I see.

So the practical solution is 

- generate asm listing
- identify appropriate jumps, eg:

        ...
        movl    8(%ecx), %eax
        jmp     .Lxxxxx
	...
.Lxxxxx:
        jmp     *%eax

- change "jmp .Lxxxxx" to "jmp *%eax" with your favorite text editor
- compile the asm source

:-)


Is there a chance, that the patch for PR15242 (if available) will go into 
3.4.3?

regards,
lajos

Re: Slowdowns in code generated by GCC>=3.3

[Daniel Berlin]

On Oct 20, 2004, at 1:30 PM, Zack Weinberg wrote:

> Földy Lajos <foldy@rmki.kfki.hu> writes:
>
>> and what about adding the real goto (which will be never executed, but
>> gcc will have "almost real" control flow):
>>
>>  	__asm__("jmp *%0" : : "a" (pc));
>> 	goto *pc;
>
> Nothing stops GCC from folding that asm into the common-ized jump
> block.

Right.
Never try to work around the express constraints given to you by the 
compiler, it will always win, and you will always lose.
:)

Re: Slowdowns in code generated by GCC>=3.3

[Zack Weinberg]

Földy Lajos <foldy@rmki.kfki.hu> writes:

> and what about adding the real goto (which will be never executed, but
> gcc will have "almost real" control flow):
>
>  	__asm__("jmp *%0" : : "a" (pc));
> 	goto *pc;

Nothing stops GCC from folding that asm into the common-ized jump
block.

zw

Re: Slowdowns in code generated by GCC>=3.3

[Földy Lajos]

On Wed, 20 Oct 2004, Zack Weinberg wrote:

> Földy Lajos <foldy@rmki.kfki.hu> writes:
> 
> > not portable, but on i386 you can try using the good old inline assembly: 
> >
> > 	void* pc;
> > 	...
> > 	pc=&&lab;
> > 	__asm__("jmp *%0" : : "a" (pc));
> > 	...
> > 	lab:
> 
> No, you can't do this.  Asm statements cannot alter control flow.
> 
> zw
> 


and what about adding the real goto (which will be never executed, but
gcc will have "almost real" control flow):

 	__asm__("jmp *%0" : : "a" (pc));
	goto *pc;

regards,
lajos

Re: Slowdowns in code generated by GCC>=3.3

[Zack Weinberg]

Földy Lajos <foldy@rmki.kfki.hu> writes:

> not portable, but on i386 you can try using the good old inline assembly: 
>
> 	void* pc;
> 	...
> 	pc=&&lab;
> 	__asm__("jmp *%0" : : "a" (pc));
> 	...
> 	lab:

No, you can't do this.  Asm statements cannot alter control flow.

zw

Re: Slowdowns in code generated by GCC>=3.3

[Földy Lajos]

> Hi,
> 
> I am a developer of a bytecode emulator for the Prolog language. With 
> the release of GCC-3.3, our emulator was slowed down by a factor of 3 on 
> x86 with -O3 turned on (we didn't measure other platforms; the 
> optimization flag doesn't seem to matter). We were hoping this was a 
> temporary issue, but the situation didn't improve in any of the newer 
> releases :( I don't know whether i should file this as a bug report, so 
> i first ask for advice her.
>
> I'll try to explain on a high level what happens. If this isn't 
> sufficient, i can try to give some code, but this will take me some time
> to isolate the code. This is the situation:
> - Since the program counter in our emulator is very crucial, we use the 
>   'register' and 'asm ("bx")' hints.
> - For each instruction in the bytecode, we store the address of the 
>   label of the code which has to be executed for the instruction. 
>   Therefore, the program counter always contains points to an address of
>   code to be executed, and after each instruction we do a 
>         goto  **(void **)program_counter
> Previous versions of GCC keep the program counter in ebx, and do a 
> jmp *(%ebx) after the instructions (as expected). The newer GCCs seem
> to unnecessarily move the program counter around between registers, and
> don't do the jmp*(%ebx) after each instruction, but seem to jump to a
> 'common' piece of code doing this jump.
>
> Looking at the changelog of gcc-3.3, i can only deduce this has to do 
> with the new DFA scheduler, but of course i can not tell for sure.
>
> I don't know if any of this information is useful, but we could use some 
> pointers in places to look where things are going wrong in the code 
> generation. The factor 3 of slowdown is really a lot.
>
> Does anyone have any ideas ?
>
> thanks a lot,
> Remko


Hi,

not portable, but on i386 you can try using the good old inline assembly: 

	void* pc;
	...
	pc=&&lab;
	__asm__("jmp *%0" : : "a" (pc));
	...
	lab:

best regards,
lajos foldy