[9fans] 8a/8l bug

[9fans] 8a/8l bug

[Latchesar Ionkov]

Hi,

I am working on making gcc to support the standard Plan9 object format. I
noticed something that IMO is a bug.

If I try to compile:

TEXT	main(SB), $0
	ADDL	$-1, AX
	ADCL	$-1, DX
	RET

the result from

	8l -a t.8
is:

001020  (1)	TEXT	main+0(SB),$0
001020 48	(2)	SUBL	$1, AX
001021 83d2ff	(3)	ADCL	$-1, DX

According to my ia32 instruction set reference 0x48 is
	DECL AX

not
	SUBL $1, AX

Unlike SUBL, DECL doesn't change CF flag, so the ADCL instruction is not
working correctly.

Where are these types of optimizations made? Is it possible to turn them off
completely?

Thanks,
	Lucho

Re: [9fans] 8a/8l bug

[Latchesar Ionkov]

Also
	ADDL	$-1, AX

is not equivalent to

	SUBL	$1, AX

The CF flag is different.

Thanks,
	Lucho

On Wed, Dec 17, 2003 at 12:59:58PM -0500, Latchesar Ionkov said:
> Hi,
>
> I am working on making gcc to support the standard Plan9 object format. I
> noticed something that IMO is a bug.
>
> If I try to compile:
>
> TEXT	main(SB), $0
> 	ADDL	$-1, AX
> 	ADCL	$-1, DX
> 	RET
>
> the result from
>
> 	8l -a t.8
> is:
>
> 001020  (1)	TEXT	main+0(SB),$0
> 001020 48	(2)	SUBL	$1, AX
> 001021 83d2ff	(3)	ADCL	$-1, DX
>
> According to my ia32 instruction set reference 0x48 is
> 	DECL AX
>
> not
> 	SUBL $1, AX
>
> Unlike SUBL, DECL doesn't change CF flag, so the ADCL instruction is not
> working correctly.
>
> Where are these types of optimizations made? Is it possible to turn them off
> completely?
>
> Thanks,
> 	Lucho

Re: [9fans] 8a/8l bug

[Russ Cox]

> Also
> 	ADDL	$-1, AX
>
> is not equivalent to
>
> 	SUBL	$1, AX
>
> The CF flag is different.

The linker is doing the "optimizations" as part of
instruction selection.  (The split of work between
compiler and loader is different than it is with gcc.)

In uchar yaddl[] = { ..., delete the two lines beginning
with Yi1.

Then you have to edit all the table entries in optab[]
that reference yaddl to remove the offending inc/dec
instructions.  But I can't remember how to decode
that table.

Russ

Re: [9fans] 8a/8l bug

[Latchesar Ionkov]

Thanks,

I already found the code and changed it. Is it likely such changes to be
accepted in the standard Plan9 distribution?

Ideally there should be an option whether to do that type of optimizations.
Unfortunately it is hard to implement the option without introducing a flag
per row in the y* arrays. The flag will be also useful for opcodes that
translate to different types of instructions some of which have 0x0f prefix,
while others don't. Currently that is not supported and it is very hard to
add support for IMUL Reg, Imm8 for example.

Would you accept patch that:

1. Adds a new option whether to do instruction optimizations.
2. Modifies y* arrays to have a flag whether the instruction code should be
used if the optimizations are on.
3. Optionally the flag also holds information whether the specific
instruction has 0x0f/0x66 headers overriding the default specified in the
optab array.

Thanks,
	Lucho

On Wed, Dec 17, 2003 at 05:54:19PM -0500, Russ Cox said:
> > Also
> > 	ADDL	$-1, AX
> >
> > is not equivalent to
> >
> > 	SUBL	$1, AX
> >
> > The CF flag is different.
>
> The linker is doing the "optimizations" as part of
> instruction selection.  (The split of work between
> compiler and loader is different than it is with gcc.)
>
> In uchar yaddl[] = { ..., delete the two lines beginning
> with Yi1.
>
> Then you have to edit all the table entries in optab[]
> that reference yaddl to remove the offending inc/dec
> instructions.  But I can't remember how to decode
> that table.
>
> Russ

Re: [9fans] 8a/8l bug

[Russ Cox]

> 1. Adds a new option whether to do instruction optimizations.
> 2. Modifies y* arrays to have a flag whether the instruction code should be
> used if the optimizations are on.

I don't want a flag to fix broken behavior.
I want the linker to do the right thing.

I'd rather change the linker just to drop the
INCL/DECL as possible ADDL/SUBL encodings
and then change the compiler if the hit is actually
significant (seems like it could be).

How many other instructions are affected?

> 3. Optionally the flag also holds information whether the specific
> instruction has 0x0f/0x66 headers overriding the default specified in the
> optab array.

If you need this to handle certain instructions, then this seems
reasonable, although I'm not sure I understand why it can't
be handled with just a separate line in the y* array.

Russ

Re: [9fans] 8a/8l bug

[Latchesar Ionkov]

On Wed, Dec 17, 2003 at 06:38:22PM -0500, Russ Cox said:
> > 1. Adds a new option whether to do instruction optimizations.
> > 2. Modifies y* arrays to have a flag whether the instruction code should be
> > used if the optimizations are on.
>
> I don't want a flag to fix broken behavior.
> I want the linker to do the right thing.
>
> I'd rather change the linker just to drop the
> INCL/DECL as possible ADDL/SUBL encodings
> and then change the compiler if the hit is actually
> significant (seems like it could be).
>
> How many other instructions are affected?
>
> > 3. Optionally the flag also holds information whether the specific
> > instruction has 0x0f/0x66 headers overriding the default specified in the
> > optab array.
>
> If you need this to handle certain instructions, then this seems
> reasonable, although I'm not sure I understand why it can't
> be handled with just a separate line in the y* array.

The flag if there should be 0x0f or 0x66 header is defined per opcode (Pm,
Pe) in optab instead of being defined per line in y*.

I already changed the machine description in gcc to avoid the problem, so I
don't need it badly, but gcc generates suboptimal code now.

BTW currently gcc compiles and executes correctly about 95% of the testcases
for C that come with it. Currently I am using gcc hosted in Linux. It uses
8a and 8l to generate the executables. When I get 98% of the testcases
correctly, I'll try C++.

Re: [9fans] 8a/8l bug

[Charles Forsyth]

a linker option seems wrong, since it's not a global attribute,
but the correctness of the substitution depends on the surrounding context.
it's usually perfectly all right to replace ADDL $1, ... by INCL for instance.

one way might be to add a pseudo-op (similar to NOSCHED) that could
be used by either assembler or compiler to constrain
instruction selection.  that's possibly a nuisance to use and implement.
another method is to have the linker check whether the shorter instruction is actually equivalent
in context to the longer one it must otherwise use, since that's really the problem here
(eg, either the flag bits are set the same way or subsequent instructions don't need them)

Re: [9fans] 8a/8l bug

[jmk]

Presotto and I looked at this earlier today.
If you take the add/sub -> inc/dec optimisation out
of 8l, you can get it all back by doing it in the
8c peephole optimiser.