2.95/3.x regression in the compilation of computed gotos?

2.95/3.x regression in the compilation of computed gotos?

[duchier]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Guys,

I'd like to get your opinion on the difference in how gcc 2.95 and
3.3.2 compile the line of code below (where PC has type void**):

	goto ** (PC += 1);

2.95:

	addl $4,%eax
        jmp *(%eax)

3.3.2:

	addl $4,%ecx
        movl (%ecx),%edx
        jmp *%edx

Isn't this a regression?

I attach below the short program used to illustrate this difference.
It reflects in a simplified manner what happens in our emulator for
mozart/oz threaded bytecode.


[-- Attachment #2: test program --]
[-- Type: text/plain, Size: 267 bytes --]

void* program[2];
int counter = 0;

#define DISPATCH(N) goto **(PC+=N)

void foo (void** PC)
{
  if (PC==0) {
    program[0] = && one;
    program[1] = && two;
    return;
  }
  DISPATCH(0);
 one:
  counter += 3;
  DISPATCH(1);
 two:
  counter += 5;
  DISPATCH(1);
}

[-- Attachment #3: Type: text/plain, Size: 77 bytes --]


Cheers,

-- 
Denys Duchier - Équipe Calligramme - LORIA, Nancy, France

Re: 2.95/3.x regression in the compilation of computed gotos?

[Robert Dewar]

duchier@ps.uni-sb.de wrote:

> 2.95:
> 
> 	addl $4,%eax
>         jmp *(%eax)
> 
> 3.3.2:
> 
> 	addl $4,%ecx
>         movl (%ecx),%edx
>         jmp *%edx
> 
> Isn't this a regression?

In such a case, it is helpful to know why you think this is a
regression. It is not clear at all to me that the 2.95 code
is better. Either attach an analysis or a timing test result.
On these kinds of machines, you can't rely on obvious common
sense to figure out what sequence of code is better!

Re: 2.95/3.x regression in the compilation of computed gotos?

[duchier]

Robert Dewar <dewar@gnat.com> writes:

> In such a case, it is helpful to know why you think this is a
> regression.

Actually, that was part of my question.  I am not sure that it is a
regression.  I was soliciting your opinion on 2 issues: (1) is it (in
principle) a regression, (2) why the difference?

I'll try to work out some code that can actually be executed, so it
can be benchmarked, but I was hoping that someone better acquainted
with instruction costs could estimate it from first principles.

Cheers,

-- 
Denys Duchier - Équipe Calligramme - LORIA, Nancy, France

Re: 2.95/3.x regression in the compilation of computed gotos?

[Richard Henderson]

On Thu, Jan 22, 2004 at 05:21:50PM +0100, duchier@ps.uni-sb.de wrote:
> Actually, that was part of my question.  I am not sure that it is a
> regression.  I was soliciting your opinion on 2 issues: (1) is it (in
> principle) a regression,

It is a *change*, yes, possibly unavoidable due to changes in the way
we process computed goto internally ...

> (2) why the difference?

... which make fantastic differences to compile-time; from hours to
minutes in some test cases.

> I'll try to work out some code that can actually be executed, so it
> can be benchmarked, but I was hoping that someone better acquainted
> with instruction costs could estimate it from first principles.

As for a *regression*, because of the way ppro, p2, p3, p4, athlon
decompose x86 instructions into risc-like internal operations, I
disbelieve anyone can measure a difference.  We still have one memory
load and one indirect jump.  That the result of the load goes to an
user -visible register rather than a cpu-internal temporary should
be immaterial.

On antiquated 80386 systems the difference is exactly 1 cycle.


r~