Re: MIPS gas relaxation still doesn't work

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Sun, Oct 13, 2002 at 02:54:23PM -0700, H. J. Lu wrote:
> On Sat, Oct 12, 2002 at 11:34:23AM -0700, H. J. Lu wrote:
> > Hi Alexandre,
> > 
> > I don't think your MIPS gas relaxation works. I got
> > 
> > # mipsel-linux-gcc /export/gnu/src/gcc-3.2/gcc/gcc/testsuite/g++.dg/opt/longbranch1.C
> > /tmp/cc0rrnMz.s: Assembler messages:
> > /tmp/cc0rrnMz.s:33733: Error: Branch out of range
> > /tmp/cc0rrnMz.s:33740: Error: Branch out of range
> > 
> > Could you please verify it?
> > 
> 
> Here is a small testcase extracted from gcc. I got
> 
> # mipsel-linux-gcc -c foo.s 
> foo.s: Assembler messages:
> foo.s:7: Error: Branch out of range
> 
> You may say it is a gcc bug. But I don't remember to see SGI assmebler
> have any problem with g++.dg/opt/longbranch1.C. Does gcc generate
> different code for Irix from Linux? Is it really unsafe to do branch
> relaxation when macro is off.
> 
> 

Here is a testcase which gas refuses to relax. I have 2 questions:

1. Does the SGI mips assembler relax it?
2. Is noreorder/nomacro really needed for gas? If I remeber right, it
is safe for gas to use

foo:
	j foo

Can gcc be be modified not to generate noreorder/nomacro for branchs if
gas is used?


H.J.
--foo.s---
foo:
	.space	0x20000
	.set    noreorder
	.set    nomacro
	j	foo
	nop
	.set    macro
	.set    reorder

Re: MIPS gas relaxation still doesn't work

[Richard Sandiford]

"H. J. Lu" <hjl@lucon.org> writes:
> Can gcc be be modified not to generate noreorder/nomacro for branchs if
> gas is used?

Sounds like you're suggesting gcc should leave gas to fill delay slots?

gcc is usually much better at filling delay slots than gas is.  gas just
looks at the previous instruction to see if it's suitable.  gcc can pull
pull instructions from the branch target instead.

Richard

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 05:09:38PM +0100, Richard Sandiford wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> > Can gcc be be modified not to generate noreorder/nomacro for branchs if
> > gas is used?
> 
> Sounds like you're suggesting gcc should leave gas to fill delay slots?
> 

Yes, when gcc doesn't know how.

> gcc is usually much better at filling delay slots than gas is.  gas just
> looks at the previous instruction to see if it's suitable.  gcc can pull
> pull instructions from the branch target instead.
> 

I don't think so. Please check out g++.dg/opt/longbranch1.C. gcc 3.2
generates:

$L7488:
        lw      $2,52($fp)
        .set    noreorder
        .set    nomacro

        bne     $2,$0,$L7493
        nop
        j       $L2
        nop

        .set    macro
        .set    reorder
$L7493:

It is no better than gas and disables the branch relaxation. I don't
why gcc shouldn't let gas handle it in this case. That is gcc should
never fill the delay slot with nop.


H.J.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> 2. Is noreorder/nomacro really needed for gas? If I remeber right, it
> is safe for gas to use

If you've already filled in delay slots, yes.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 02:19:28PM -0200, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > 2. Is noreorder/nomacro really needed for gas? If I remeber right, it
> > is safe for gas to use
> 
> If you've already filled in delay slots, yes.
> 

Not when you fill it with nop :-).


H.J.

Re: MIPS gas relaxation still doesn't work

[Richard Sandiford]

"H. J. Lu" <hjl@lucon.org> writes:
> > gcc is usually much better at filling delay slots than gas is.  gas just
> > looks at the previous instruction to see if it's suitable.  gcc can pull
> > pull instructions from the branch target instead.
> 
> I don't think so. Please check out g++.dg/opt/longbranch1.C. gcc 3.2
> generates:
> 
> $L7488:
>         lw      $2,52($fp)
>         .set    noreorder
>         .set    nomacro
> 
>         bne     $2,$0,$L7493
>         nop
>         j       $L2
>         nop
> 
>         .set    macro
>         .set    reorder
> $L7493:
> 
> It is no better than gas and disables the branch relaxation. I don't
> why gcc shouldn't let gas handle it in this case. That is gcc should
> never fill the delay slot with nop.

Huh?  Obviously there are going to be cases when neither gcc nor
gas can fill a slot.  Just because you've found one doesn't mean
that gcc never fills a delay that gas wouldn't.  Compare gcc's
dbr_schedule with gas's append_insn.

The fact gcc fills this slot with a nop is just incidental.
gcc is not written on the assumption that the assembler will
relax branches.  It's easy to see it filling that slot with
a non-nop in other cases.  And, what's more, filling it with
a non-nop that gas wouldn't consider.

When you said:

> Can gcc be be modified not to generate noreorder/nomacro for branchs if
> gas is used?

you seemed to be arguing that gcc should start relying on
branch relaxation, but that really seems the wrong way to go.

Richard

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 05:35:00PM +0100, Richard Sandiford wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> > > gcc is usually much better at filling delay slots than gas is.  gas just
> > > looks at the previous instruction to see if it's suitable.  gcc can pull
> > > pull instructions from the branch target instead.
> > 
> > I don't think so. Please check out g++.dg/opt/longbranch1.C. gcc 3.2
> > generates:
> > 
> > $L7488:
> >         lw      $2,52($fp)
> >         .set    noreorder
> >         .set    nomacro
> > 
> >         bne     $2,$0,$L7493
> >         nop
> >         j       $L2
> >         nop
> > 
> >         .set    macro
> >         .set    reorder
> > $L7493:
> > 
> > It is no better than gas and disables the branch relaxation. I don't
> > why gcc shouldn't let gas handle it in this case. That is gcc should
> > never fill the delay slot with nop.
> 
> Huh?  Obviously there are going to be cases when neither gcc nor
> gas can fill a slot.  Just because you've found one doesn't mean
> that gcc never fills a delay that gas wouldn't.  Compare gcc's
> dbr_schedule with gas's append_insn.
> 
> The fact gcc fills this slot with a nop is just incidental.
> gcc is not written on the assumption that the assembler will
> relax branches.  It's easy to see it filling that slot with
> a non-nop in other cases.  And, what's more, filling it with
> a non-nop that gas wouldn't consider.
> 

The problem here is when gcc fills the delay slot with nop, it kills
branch relaxation. My request is gcc never fills the delay slot with
nop. If gcc can't find any insn to fill, don't emit .set noreorder.



H.J.

Re: MIPS gas relaxation still doesn't work

[David S. Miller]

   From: "H. J. Lu" <hjl@lucon.org>
   Date: Mon, 14 Oct 2002 10:16:40 -0700
   
   The problem here is when gcc fills the delay slot with nop, it kills
   branch relaxation. My request is gcc never fills the delay slot with
   nop. If gcc can't find any insn to fill, don't emit .set noreorder.

Why not work on making gcc fill the delay slot with something
suitable if you think the branch relaxer can do better for
your testcase?

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 10:13:18AM -0700, David S. Miller wrote:
>    From: "H. J. Lu" <hjl@lucon.org>
>    Date: Mon, 14 Oct 2002 10:16:40 -0700
>    
>    The problem here is when gcc fills the delay slot with nop, it kills
>    branch relaxation. My request is gcc never fills the delay slot with
>    nop. If gcc can't find any insn to fill, don't emit .set noreorder.
> 
> Why not work on making gcc fill the delay slot with something
> suitable if you think the branch relaxer can do better for
> your testcase?

I never said gas could find better insn to fill the delay slot. It is
just that it won't kill the branch relaxation. There is no gain, and
only loss, for gcc to fill the delay slot with nop.


H.J.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> The problem here is when gcc fills the delay slot with nop, it kills
> branch relaxation.

It wouldn't if only the delay slot was enclosed in .set nomacro.
Could we change this?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 02:43:26PM -0300, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > The problem here is when gcc fills the delay slot with nop, it kills
> > branch relaxation.
> 
> It wouldn't if only the delay slot was enclosed in .set nomacro.

What do you mean by that?

> Could we change this?
> 



H.J.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> On Mon, Oct 14, 2002 at 02:43:26PM -0300, Alexandre Oliva wrote:
>> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
>> 
>> > The problem here is when gcc fills the delay slot with nop, it kills
>> > branch relaxation.
>> 
>> It wouldn't if only the delay slot was enclosed in .set nomacro.

> What do you mean by that?

Instead of:

.set noreorder
.set nomacro
b foo
nop
.set macro
.set reorder

perhaps we could emit:

.set noreorder
b foo
.set nomacro
nop
.set macro
.set reorder


Since b foo wouldn't be affected by nomacro, branch relaxing could
fix it up (the relaxations are delay-slot-safe).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 02:58:04PM -0300, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Mon, Oct 14, 2002 at 02:43:26PM -0300, Alexandre Oliva wrote:
> >> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> >> 
> >> > The problem here is when gcc fills the delay slot with nop, it kills
> >> > branch relaxation.
> >> 
> >> It wouldn't if only the delay slot was enclosed in .set nomacro.
> 
> > What do you mean by that?
> 
> Instead of:
> 
> .set noreorder
> .set nomacro
> b foo
> nop
> .set macro
> .set reorder
> 
> perhaps we could emit:
> 
> .set noreorder
> b foo
> .set nomacro
> nop
> .set macro
> .set reorder
> 
> 
> Since b foo wouldn't be affected by nomacro, branch relaxing could
> fix it up (the relaxations are delay-slot-safe).

Why do we need nop? Why do we need noreorder?


H.J.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> Why do we need nop? Why do we need noreorder?

We need reorder to indicate that the delay slot is already filled.  I
used nop just because it was the easiest form of delay-slot filling I
could think of.  Think of any other valid delay-slot filling
instruction in there.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 04:37:37PM -0300, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > Why do we need nop? Why do we need noreorder?
> 
> We need reorder to indicate that the delay slot is already filled.  I
> used nop just because it was the easiest form of delay-slot filling I
> could think of.  Think of any other valid delay-slot filling
> instruction in there.

Can gcc not to emit nop nor noreorder when it tries to fill the delay
slot with nop?


H.J.

Re: MIPS gas relaxation still doesn't work

[David S. Miller]

   From: "H. J. Lu" <hjl@lucon.org>
   Date: Mon, 14 Oct 2002 12:39:40 -0700
   
   Can gcc not to emit nop nor noreorder when it tries to fill the delay
   slot with nop?

All the surrounding instructions scheduled by GCC are within
noreorder sections aren't they?

If so, the assembler has nothing to put into the delay
slot.

If not, you have a valid point, we should just remit the branch
by itself with no reorder/macro section attributes.

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 12:35:10PM -0700, David S. Miller wrote:
>    From: "H. J. Lu" <hjl@lucon.org>
>    Date: Mon, 14 Oct 2002 12:39:40 -0700
>    
>    Can gcc not to emit nop nor noreorder when it tries to fill the delay
>    slot with nop?
> 
> All the surrounding instructions scheduled by GCC are within
> noreorder sections aren't they?
> 
> If so, the assembler has nothing to put into the delay
> slot.
> 
> If not, you have a valid point, we should just remit the branch
> by itself with no reorder/macro section attributes.

Does

        .set    noreorder
        .set    nomacro

        bne     $2,$0,$L7493
        nop
        j       $L2
        nop

        .set    macro
        .set    reorder

answer your question?


H.J.

Re: MIPS gas relaxation still doesn't work

[David S. Miller]

   From: "H. J. Lu" <hjl@lucon.org>
   Date: Mon, 14 Oct 2002 12:55:49 -0700

           .set    noreorder
           .set    nomacro
   
           bne     $2,$0,$L7493
           nop
           j       $L2
           nop
   
           .set    macro
           .set    reorder
   
   answer your question?
   
   
What instruction would you like to place in the bne's delay
slot?  'j' cannot go into a delay slot.

And likewise, 'bne' cannot go into j's delay slot.

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 12:51:34PM -0700, David S. Miller wrote:
>    From: "H. J. Lu" <hjl@lucon.org>
>    Date: Mon, 14 Oct 2002 12:55:49 -0700
> 
>            .set    noreorder
>            .set    nomacro
>    
>            bne     $2,$0,$L7493
>            nop
>            j       $L2
>            nop
>    
>            .set    macro
>            .set    reorder
>    
>    answer your question?
>    
>    
> What instruction would you like to place in the bne's delay
> slot?  'j' cannot go into a delay slot.
> 
> And likewise, 'bne' cannot go into j's delay slot.

If gcc just emits

	bne     $2,$0,$L7493
	j       $L2

gas will fill the delay slot with nop or branch relaxation. For

bar:
foo:
	.space	0x20000
	bne     $2,$0,bar
	j	foo

gas generates

foo.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <bar>:
	...
   20000:	10400005 	beqz	v0,20018 <bar+0x20018>
   20004:	00000000 	nop
   20008:	8f810000 	lw	at,0(gp)
			20008: R_MIPS_GOT16	.text
   2000c:	00000000 	nop
   20010:	24210000 	addiu	at,at,0
			20010: R_MIPS_LO16	.text
   20014:	00200008 	jr	at
   20018:	00000000 	nop
   2001c:	8f810000 	lw	at,0(gp)
			2001c: R_MIPS_GOT16	.text
   20020:	00000000 	nop
   20024:	24210000 	addiu	at,at,0
			20024: R_MIPS_LO16	.text
   20028:	00200008 	jr	at
   2002c:	00000000 	nop

H.J.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> If gcc just emits

> 	bne     $2,$0,$L7493
> 	j       $L2

IIRC, that's exactly what GCC will emit if you don't tell it to try to
fill delay slots.  If it tries to fill delay slots and fails, I doubt
the assembler is going to succeed at that.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 05:20:55PM -0300, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > If gcc just emits
> 
> > 	bne     $2,$0,$L7493
> > 	j       $L2
> 
> IIRC, that's exactly what GCC will emit if you don't tell it to try to
> fill delay slots.  If it tries to fill delay slots and fails, I doubt
> the assembler is going to succeed at that.

Is that a way to tell gcc not to fill the delay slots with nop? If gcc
has nothing else to fill, do nothing and let gas do its thing.


H.J.

Re: MIPS gas relaxation still doesn't work

[Michael Matz]

Hi,

On 14 Oct 2002, Alexandre Oliva wrote:

> > If gcc just emits
>
> > 	bne     $2,$0,$L7493
> > 	j       $L2
>
> IIRC, that's exactly what GCC will emit if you don't tell it to try to
> fill delay slots.  If it tries to fill delay slots and fails, I doubt
> the assembler is going to succeed at that.

I think that isn't hj's point.  He wanta gas to take advantage of
relaxation, and gcc is hindering that for no good reason.  I admit I have
no idea of Mips, though, so I don't know if relaxation somehow is
depending on delay slot filling at all ;-)


Ciao,
Michael.

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> On Mon, Oct 14, 2002 at 05:20:55PM -0300, Alexandre Oliva wrote:

>> If it tries to fill delay slots and fails, I doubt the assembler is
>> going to succeed at that.

> Is that a way to tell gcc not to fill the delay slots with nop? If gcc
> has nothing else to fill, do nothing and let gas do its thing.

See above.  You'd be just wasting time.  If you have a testcase in
which gcc tries to fill the delay slot and fails even though it could,
you've found a bug in gcc, and this bug should be fixed.  Wasting time
in the assembler trying again to do what gcc should have done is
silly.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[H. J. Lu]

On Mon, Oct 14, 2002 at 06:06:24PM -0300, Alexandre Oliva wrote:
> On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> 
> > On Mon, Oct 14, 2002 at 05:20:55PM -0300, Alexandre Oliva wrote:
> 
> >> If it tries to fill delay slots and fails, I doubt the assembler is
> >> going to succeed at that.
> 
> > Is that a way to tell gcc not to fill the delay slots with nop? If gcc
> > has nothing else to fill, do nothing and let gas do its thing.
> 
> See above.  You'd be just wasting time.  If you have a testcase in
> which gcc tries to fill the delay slot and fails even though it could,
> you've found a bug in gcc, and this bug should be fixed.  Wasting time
> in the assembler trying again to do what gcc should have done is
> silly.
> 

Have you ever tried g++.dg/opt/longbranch1.C in gcc 3.2 for ELF/mips?
I have asked it many times. No, you don't need a mips board. It is
a link only test. If you want, I can tell you where you can find a
complete cross toolchain for Linux/mips hosted on Linux/x86.


H.J.

Re: MIPS gas relaxation still doesn't work

[Eric Christopher]

On Mon, 2002-10-14 at 13:23, H. J. Lu wrote:
> On Mon, Oct 14, 2002 at 05:20:55PM -0300, Alexandre Oliva wrote:
> > On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
> > 
> > > If gcc just emits
> > 
> > > 	bne     $2,$0,$L7493
> > > 	j       $L2
> > 
> > IIRC, that's exactly what GCC will emit if you don't tell it to try to
> > fill delay slots.  If it tries to fill delay slots and fails, I doubt
> > the assembler is going to succeed at that.
> 
> Is that a way to tell gcc not to fill the delay slots with nop? If gcc
> has nothing else to fill, do nothing and let gas do its thing.
> 

Read mips_output_conditional_branch ()

-eric

-- 
Yeah, I used to play basketball...

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:

> Have you ever tried g++.dg/opt/longbranch1.C in gcc 3.2 for ELF/mips?

Yes, I have, and it has failed in the past.  I don't know about the
current status and, frankly, I don't understand what point you're
trying to make waving your hands in the general direction of
longbranch1.C while discussing whether gas would have any chance of
filling a delay slot that gcc has failed to fill.

> If you want, I can tell you where you can find a complete cross
> toolchain for Linux/mips hosted on Linux/x86.

Thanks, I've built such toolchains more than once a day lately :-)

I know the problem that branch relaxation is intended to solve: it's a
work around for a long-standing bug in the compiler.  In that it
apparently assumes that the expansion of certain macros is shorter
than they actually are, so it ends up not doing branch shortening in
some necessary situations.  This gets even worse with mips16, in which
we don't do branch shortening, and the assembler doesn't do branch
relaxation.

But while you're trying to paper over the problem, others are
rewriting the mips back end so as to not make use of macros, such that
instruction lengths will be more accurate and then branch shortening
will (hopefully) work correctly.

The compiler is the right place in which to fix out-of-range jumps,
because the compiler has better information on how to reduce the
performance impact of such transformation.  It can be fixed in the
assembler, but it can't be done as efficiently.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 14, 2002, Eric Christopher <echristo@redhat.com> wrote:

> On Mon, 2002-10-14 at 13:23, H. J. Lu wrote:
>> On Mon, Oct 14, 2002 at 05:20:55PM -0300, Alexandre Oliva wrote:
>> > On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote:
>> > 
>> > > If gcc just emits
>> > 
>> > > 	bne     $2,$0,$L7493
>> > > 	j       $L2
>> > 
>> > IIRC, that's exactly what GCC will emit if you don't tell it to try to
>> > fill delay slots.  If it tries to fill delay slots and fails, I doubt
>> > the assembler is going to succeed at that.
>> 
>> Is that a way to tell gcc not to fill the delay slots with nop? If gcc
>> has nothing else to fill, do nothing and let gas do its thing.

> Read mips_output_conditional_branch ()

That part I'm familiar with.  The part I'm not familiar with is
whether this would trigger problems in say the SGI assembler, or
whether such reordering of .sets would violate some MIPS assembler
specification I'm not familiar with.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Dominic Sweetman]

Alexandre,

> I know the problem that branch relaxation [aka delay-slot filling by
> the assembler] is intended to solve: it's a
> work around for a long-standing bug in the compiler.  In that it
> apparently assumes that the expansion of certain macros is shorter
> than they actually are, so it ends up not doing branch shortening in
> some necessary situations.  This gets even worse with mips16, in which
> we don't do branch shortening, and the assembler doesn't do branch
> relaxation.

This true - but it isn't why it's there.  Getting the assembler
involved goes back to the early 1980s roots of the MIPS project:

o It saved putting novel and interesting code into compilers.  A safe
  and quick hack to the assembler probably catches more than half the
  delay slots available; anything other than very clever compiler work
  might do little better.  Nobody should forget that most 
  'commercial' compilers are even more ghastly than gcc.

o It concealed the deeply unfamiliar and counter-intuitive "delay
  slot" from the assembler programmer.

o At the time, MIPS' assembler was related to a DoD initiative to
  write mission-critical software via a
  slightly-higher-than-machine-language assembly code - a kind of
  "what if Ada doesn't work?" project.  As such, there was good reason
  to get the *compiler* to target assembler language.

The first GCC ports for MIPS were quick hacks using the MIPS
assembler. They made liberal use of what were effectively macro
instructions.  RISC CPUs were kind of new, and back-end coders quailed
at a machine which had no register-to-register move and where even the
nop is an alias.  More pernicious, as you say, is the use of macros
such as "la" or even "lw" which expand different ways...

Which got a whole lot worse when gcc/gas was hacked again for position
independent code and the bulk of that work was done in the assembler.

> But while you're trying to paper over the problem, others are
> rewriting the mips back end so as to not make use of macros, such that
> instruction lengths will be more accurate and then branch shortening
> will (hopefully) work correctly.

Other pressures, unfortunately, operate the other way; you could
generate substantially better position-independent MIPS code if you
were prepared to avoid committing the final instruction sequence until
the link which produced the executable or shared object...

But getting the assembler macros out of the compiler is a long-overdue
reform.

Algorithmics (now part of MIPS) have been chiselling away at this for
a long while, but opportunistically rather than as a focussed problem.
Moreover, our limited resource + the poor state of standard gcc
releases (at least up to two years ago) meant that producing a decent
usable compiler always took us so long that by the time it worked our
codebase was too old to facilitate changes going back.  We do have a
lot of useful changes for MIPS, and aim to resynchronise to 3.x and 
make a substantial attempt to get those changes back into the main
source trees, perhaps in 6 months time.

Meanwhile, do you have some sense of a plausible team and a schedule
for this reform in the 3.1.x codebase?

-- 
Dominic Sweetman
MIPS Technologies (formerly Algorithmics Ltd)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 15, 2002, Dominic Sweetman <dom@algor.co.uk> wrote:

> Alexandre,

>> I know the problem that branch relaxation [aka delay-slot filling by
>> the assembler] is intended to solve

You got something wrong when you added this editor note.  Branch
relaxation and delay-slot filling are an entirely different issues.
Compare branch relaxation, that turns:

beq $t4,foo
[.... lots of code such that the branch is out of range....]
foo:

into

bne $t4,0f,foo
nop
j foo
nop
0:
[.... lots of code that won't make the jump out of range....]
foo:


with delay-slot filling, that turns:

move $a0,$s3
jal foo

into

jal foo
move $a0,$s3


See any resemblance?  Me neither.


The rest of your posting seems to be based on the mis-assumption that
branch relaxation and delay-slot filling are the same thing, so I'll
refrain from making further comments.


As for schedule, it's definitely not for 3.1, since 3.1 is already
out, and so is 3.2, and even 3.3 is already feature-frozen.  As the
name of the mips rewrite branch says, it's targeted at 3.4.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 15 Oct 2002, Alexandre Oliva wrote:

> The compiler is the right place in which to fix out-of-range jumps,
> because the compiler has better information on how to reduce the
> performance impact of such transformation.  It can be fixed in the
> assembler, but it can't be done as efficiently.

 Except that the compiler does not always have the knowledge, particularly
when inline assembly bits (insolvable) or macros such as "la" (unless gcc
gets a full-blown ABI-dependent machinery implemented) are involved.

 I think at least for the former case gas should be let relax jumps and
branches freely, so the ".set nomacro" statement should be moved to affect
instructions in delay slots only, as you suggested.

 For the latter, gas could be able to move parts of macro expansions into
delay slots and it sometimes succeeds, though it isn't particularly good
at it.  Try to assemble e.g.: "bar: lw $2,foo; b bar" for o32/PIC and for
n32/PIC.  It can't be optimized by gcc, if to be emitted, any further
currently and gas (2.13) fails that miserably for the former: 

lw.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <bar>:
   0:	8f820000 	lw	v0,0(gp)
			0: R_MIPS_GOT16	foo
   4:	00000000 	nop
   8:	8c420000 	lw	v0,0(v0)
   c:	1000fffc 	b	0 <bar>
  10:	00000000 	nop
	...

but it succeeds for the latter!:

lw64.o:     file format elf64-tradlittlemips

Disassembly of section .text:

0000000000000000 <bar>:
   0:	df820000 	ld	v0,0(gp)
			0: R_MIPS_GOT_PAGE	foo
   4:	64420000 	daddiu	v0,v0,0
			4: R_MIPS_GOT_OFST	foo
   8:	1000fffd 	b	0 <bar>
   c:	8c420000 	lw	v0,0(v0)

So there is still a small gain from letting gas try to fill slots usefully
when gcc can't.  Therefore, I agree with H. J. here -- if gcc is about to
put a "nop" into a branch delay, it'd better give it up together with the
".set noreorder" directive, letting gas try again if it can come with
something better.  This isn't ever going to hurt, whether gcc gets smarter
or not, unless gas stops filling delay slots one day, which is unlikely, I
hope.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

>Can gcc not to emit nop nor noreorder when it tries to fill the delay
>slot with nop?

You never want the assembler to try to fill delay slots.  Consider a compiler
optimization like software pipelining.  The compiler will schedule instructions
inside a loop with full knowledge of the target pipeline to give maximum
performance.  Then the assembler picks a random instruction from the loop,
puts it in a branch delay slot, and now your code runs twice as slow because
the assembler introduced pipeline stalls.  Of course, gcc isn't good enough
yet to have this problem yet, but we will get there eventually.  Meanwhile, we
need to get out of the habit of relying on assembler optimizations.  In the
long run, assembler optimizations are bad, and we need to stop using them as
soon as possible.  Gcc should emit .set nomacro/noreorder/noat/etc at the
begining of its assembly output, and never turn them on.

Jim

Re: MIPS gas relaxation still doesn't work

[Paul Koning]

>>>>> "Jim" == Jim Wilson <wilson@redhat.com> writes:

 >> Can gcc not to emit nop nor noreorder when it tries to fill the
 >> delay slot with nop?

 Jim> You never want the assembler to try to fill delay slots.
 Jim> Consider a compiler optimization like software pipelining. ...
 Jim>  Meanwhile, we need to get out of
 Jim> the habit of relying on assembler optimizations.  In the long
 Jim> run, assembler optimizations are bad, and we need to stop using
 Jim> them as soon as possible.  Gcc should emit .set
 Jim> nomacro/noreorder/noat/etc at the begining of its assembly
 Jim> output, and never turn them on.

Makes sense to me.  As an assembly language programmer, I do the same
thing in handwritten code, for the same reasons.

      paul

Re: MIPS gas relaxation still doesn't work

[Daniel Jacobowitz]

On Tue, Oct 15, 2002 at 03:58:57PM -0400, Jim Wilson wrote:
> >Can gcc not to emit nop nor noreorder when it tries to fill the delay
> >slot with nop?
> 
> You never want the assembler to try to fill delay slots.  Consider a compiler
> optimization like software pipelining.  The compiler will schedule instructions
> inside a loop with full knowledge of the target pipeline to give maximum
> performance.  Then the assembler picks a random instruction from the loop,
> puts it in a branch delay slot, and now your code runs twice as slow because
> the assembler introduced pipeline stalls.  Of course, gcc isn't good enough
> yet to have this problem yet, but we will get there eventually.  Meanwhile, we
> need to get out of the habit of relying on assembler optimizations.  In the
> long run, assembler optimizations are bad, and we need to stop using them as
> soon as possible.  Gcc should emit .set nomacro/noreorder/noat/etc at the
> begining of its assembly output, and never turn them on.

While I agree with you in theory, how would GCC handle user-written
asm("") blocks without an assemble-time jump relaxation of some sort?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

Your historical info is only partly accurate.

You are right about the beginning part.  In the beginning there was MIPS,
and MIPS wrote a toolchain that tried to be friendly to assembly language
programmers.  Because of this, some optimizations, mainly instruction
scheduling and delay-slot filling, were implemented in the assembler instead
of the compiler, so that they would be usuable to assembly language
programmers.  Since gcc/binutils usually follows conventions set by the
vendor, gcc/binutils did things the same way.

Later, gcc started using its own instruction scheduler and delay-slot filling
optimization passes, but we never fully moved away from relying on assembler
optimizations.

>The first GCC ports for MIPS were quick hacks using the MIPS
>assembler. They made liberal use of what were effectively macro
>instructions. 

I think this is inaccurate in a number of ways.  It is a gcc convention
to use the native assembler whenever possible, and be compatible with the
native assembler language.  We write our own assembler only when the native
one isn't good enough to bootstrap gcc, or when there is no other native
assembler, e.g. embedded and linux targets.  Similarly, we create our own
assembler language only when there isn't an existing one we can use.  So there
was nothing wrong with using the MIPS/SGI assembler for the original gcc ports.
Also, gcc followed the conventions set by the MIPS/SGI compilers, which used
macro instructions very heavily.  Thus gcc used macro instructions heavily
also.  In hindsight this was a mistake, but at the time it wasn't so obvious.

>Which got a whole lot worse when gcc/gas was hacked again for position
>independent code and the bulk of that work was done in the assembler.

I agree everything got a lot uglier when PIC support was added.  However,
it was SGI that did it first in the assembler, and gcc/gas just followed
exactly the conventions that were defined and implemented by SGI, in order
to maintain compatibility with SGI systems.

When we added PIC support for embedded systems, it was just more of the same.

>But getting the assembler macros out of the compiler is a long-overdue
>reform.

Definitely.

SGI eventually realized their original toolchain design was limiting their
performance, and when SGI introduced their 64-bit Irix6 workstations, they
used this as an excuse to write a new compiler from scratch in which all
optimizations were performed in the compiler, and no assembler optimizations
were used at all.  Gcc has unfortunately not made the switch over yet, but
people are working on it.  Once again, we are following conventions defined
by SGI.

Jim

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On Tue, 15 Oct 2002, Paul Koning wrote:

>  Jim> them as soon as possible.  Gcc should emit .set
>  Jim> nomacro/noreorder/noat/etc at the begining of its assembly
>  Jim> output, and never turn them on.
> 
> Makes sense to me.  As an assembly language programmer, I do the same
> thing in handwritten code, for the same reasons.

 Hmm, how do you select right relocations that depend on the ABI selected? 
A common macro like "lw $2,foo" may expand in three different ways
depending on which one of "-mabi=<o32|n32|64>" is used and other three
ones for "-KPIC", plus possibly more depending on other options or "foo"
itself.  Good luck handling it with "ifdefs".

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Eric Christopher]

> While I agree with you in theory, how would GCC handle user-written
> asm("") blocks without an assemble-time jump relaxation of some sort?
> 

Treat them as regions that cannot be scheduled across I believe.

-eric

-- 
Yeah, I used to play basketball...

Re: MIPS gas relaxation still doesn't work

[Daniel Jacobowitz]

On Tue, Oct 15, 2002 at 01:56:47PM -0700, Eric Christopher wrote:
> 
> > While I agree with you in theory, how would GCC handle user-written
> > asm("") blocks without an assemble-time jump relaxation of some sort?
> > 
> 
> Treat them as regions that cannot be scheduled across I believe.

No, I mean the problem that Maciej raised: how can we even pretend to
know their length?  They're a black box; we don't really want to assume
that long jumps are necessary over one, but we don't know how big they
are.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

>While I agree with you in theory, how would GCC handle user-written
>asm("") blocks without an assemble-time jump relaxation of some sort?

That is a problem I haven't considered in detail.

We don't have to worry about handling branches inside the extended asm.  Gcc
doesn't allow branching into or outof an extended asm.  So we only have to
worry about branches across the asm.

Gcc knows how many individual instructions are in an extended asm.  We count
the separators, which is usually a ';', though this is configurable.  Then we
multiply by the architecture defined default instruction size.  We can make
this an arbitrarily large value for extended asms if we want.  We could set
this to the size of the largest macro expansion, which would solve the general
case.  If we assume that asms are rare, then there should be very little
performance loss from this over general assumption.

It has always been the case that extended asms are a hook to gcc internals
which work only if you know how gcc internals work.  So we could perhaps try
to define away the problem by saying that extended asms that use macro
instructions are no longer supported.  Some people might not like that,
but if we explain that it is necessary to improve gcc performance then
perhaps they will understand.

Worst case, we change the extended asm syntax so that people can specify the
worst case size of them.  I'd rather not do that though.

Jim

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 15, 2002, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  Hmm, how do you select right relocations that depend on the ABI selected? 

Err...  With logic similar to that the assembler uses? :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

> Except that the compiler does not always have the knowledge, particularly
>when inline assembly bits (insolvable) or macros such as "la" (unless gcc
>gets a full-blown ABI-dependent machinery implemented) are involved.

There is a natural conflict between compiler optimization and assembler
optimization/assembler macro expansion.  If you want the best possible
compiler optimization, then you need to be willing to give up use of
assembler optimizations and assembler macros.  That includes uses in extended
asms.  We can make that work if we have to, but it is better if we don't have
to.

> For the latter, gas could be able to move parts of macro expansions into
>delay slots and it sometimes succeeds, though it isn't particularly good
>at it.

This is ISA confusion.  When you ask gas to generate o32/PIC code, it assumes
the least common denominator, which is the R2000.  The R2000 does not have
hardware interlocks on loads.  It requires a nop in between a load and the
instruction that uses the result of the load.  Therefore, we can not put a
load in a delay slot unless we know that the instruction at the branch target
does not use the result of the load.  Since gas doesn't bother to construct
a control flow graph, we have no idea what is at the branch target, and
therefore we can't put a load in the branch delay slot.

When you ask gas to generate n32/PIC code, the least common denominator is
the R4000, which does have hardware interlocks on loads, and thus we can put
a load into a delay slot.

If you ask gas to generate R4000 o32/PIC code, it will fill the delay slot
exactly like you wanted, but the code may fail at run time on some mips
processors.

> It can't be optimized by gcc, if to be emitted,

It can be optimized if we use direct cpu instructions instead of relying
on assembler macros.  Then gcc would know about the load instructions, and
would be able to place one in the branch delay slot (assuming a R4000 or
better target).

The MIPS gcc target is the only one that has this problem, because it is the
only one that relies on assembler macros for PIC support.

>So there is still a small gain from letting gas try to fill slots usefully
>when gcc can't. ...
> This isn't ever going to hurt, whether gcc gets smarter
>or not,

Yes it can hurt.  If gcc decides the optimal code for a loop requires putting
a nop in a branch delay slot, then the assembler would hurt performance if
it put another instruction there.

If your main concern is only extended asm code writting using assembler macros,
then that can be fixed by turning on assembler optimization within the
extended asm code.  In the long run though, you are better off if you stop
using assembler macros.

Jim

Re: MIPS gas relaxation still doesn't work

[Richard Henderson]

On Mon, Oct 14, 2002 at 12:39:40PM -0700, H. J. Lu wrote:
> Can gcc not to emit nop nor noreorder when it tries to fill the delay
> slot with nop?

Because Ideally, gcc will emit

	.set nomacro
	.set noreorder

at the top of the assembly file and never change it.
I hope Eric's mips-rewrite-branch makes it this far.


r~

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 15, 2002, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  I think at least for the former case gas should be let relax jumps and
> branches freely, so the ".set nomacro" statement should be moved to affect
> instructions in delay slots only, as you suggested.

Except that, with the current implementation of branch relaxation,
when you enable it, each branch will mark the end of a frag, so the
assembler will be effectively unable to fill delay slots anyway, since
it won't bring instructions from the previous frag to the beginning of
the new frag.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 15 Oct 2002, Alexandre Oliva wrote:

> >  Hmm, how do you select right relocations that depend on the ABI selected? 
> 
> Err...  With logic similar to that the assembler uses? :-)

 Except that at the assembly level you cannot guess which switches were
passed to gas.  You may try to guess with cpp, but it isn't able to get at
whatever is passed with "-Wa".  Also you have to reflect all the
conditional paths from the "asm" sections of specs in the "cpp" ones,
which is fragile. 

 Pretty tough at the moment, I'd say.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 15 Oct 2002, Jim Wilson wrote:

> It has always been the case that extended asms are a hook to gcc internals
> which work only if you know how gcc internals work.  So we could perhaps try
> to define away the problem by saying that extended asms that use macro
> instructions are no longer supported.  Some people might not like that,
> but if we explain that it is necessary to improve gcc performance then
> perhaps they will understand.

 Perhaps if gcc provides some aid in dealing with cases you'd want to use
macros, I will.  The tough problems I've noticed so far is the small limit
on the number of constraints, which is only ten, and the unability to pass
a machine address, as the "R" constraint, which is expected to provide the
function, doesn't work here and the "m" and "o" ones may require a macro
expansion.  I will look into both problems in the future but I won't mind
if someone does sooner.  Especially the latter one seems to require major
changes to gcc. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 15 Oct 2002, Jim Wilson wrote:

> There is a natural conflict between compiler optimization and assembler
> optimization/assembler macro expansion.  If you want the best possible
> compiler optimization, then you need to be willing to give up use of
> assembler optimizations and assembler macros.  That includes uses in extended
> asms.  We can make that work if we have to, but it is better if we don't have
> to.

 If gcc can fully handle all possible cases that gas does, I see no
problem.  That may be beneficial if done well, but will require care to
track changes done to both code generation engines to make sure they are
in sync.  If gcc keeps the recent good habit of frequent releases, then
it's perfecty acceptable.

> This is ISA confusion.  When you ask gas to generate o32/PIC code, it assumes
> the least common denominator, which is the R2000.  The R2000 does not have
> hardware interlocks on loads.  It requires a nop in between a load and the
> instruction that uses the result of the load.  Therefore, we can not put a
> load in a delay slot unless we know that the instruction at the branch target
> does not use the result of the load.  Since gas doesn't bother to construct
> a control flow graph, we have no idea what is at the branch target, and
> therefore we can't put a load in the branch delay slot.

 I'm sorry, I missed the load delay slot property first and only some time
later I recalled it (shame on me -- I even own an R3k system ;-) ).  Still
for "-mips2" the code is not exactly perfect:

la2.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <bar>:
   0:	8f820000 	lw	v0,0(gp)
			0: R_MIPS_GOT16	foo
   4:	00000000 	nop
   8:	1000fffd 	b	0 <bar>
   c:	8c420000 	lw	v0,0(v0)

The "nop" is unnecessary.

> It can be optimized if we use direct cpu instructions instead of relying
> on assembler macros.  Then gcc would know about the load instructions, and
> would be able to place one in the branch delay slot (assuming a R4000 or
> better target).

 To nitpick, actually an R6000 suffices. ;-)

> The MIPS gcc target is the only one that has this problem, because it is the
> only one that relies on assembler macros for PIC support.

 So it does for non-PIC.

> Yes it can hurt.  If gcc decides the optimal code for a loop requires putting
> a nop in a branch delay slot, then the assembler would hurt performance if
> it put another instruction there.

 Once it only emits machine instructions and it can really judge the "nop"
is a win -- I agree.  Still it may emit ".set reorder; .set macro" if it
cannot judge for some reason.

> If your main concern is only extended asm code writting using assembler macros,
> then that can be fixed by turning on assembler optimization within the
> extended asm code.  In the long run though, you are better off if you stop
> using assembler macros.

 As soon as gcc supports plain machine instructions well, as I wrote in
another mail, I see no showstopper problems.  Though putting a "nop" 
surrounded with an "ifdef" clause in all load delay slots you cannot
usefully fill is not nice -- maybe a "%" code could be added to gcc to let
an assembly programmer express these "nop" fillers in a way gcc would know
about them and be able to remove them if unneeded. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 15 Oct 2002, Alexandre Oliva wrote:

> Except that, with the current implementation of branch relaxation,
> when you enable it, each branch will mark the end of a frag, so the
> assembler will be effectively unable to fill delay slots anyway, since
> it won't bring instructions from the previous frag to the beginning of
> the new frag.

 Too bad.  But the marking could get disabled if ".set nomacro" was on for
a branch, couldn't it?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Alexandre Oliva]

On Oct 16, 2002, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

> On 15 Oct 2002, Alexandre Oliva wrote:
>> Except that, with the current implementation of branch relaxation,
>> when you enable it, each branch will mark the end of a frag, so the
>> assembler will be effectively unable to fill delay slots anyway, since
>> it won't bring instructions from the previous frag to the beginning of
>> the new frag.

>  Too bad.  But the marking could get disabled if ".set nomacro" was on for
> a branch, couldn't it?

Err...  Yes, indeed, this is already the case, now that I think of
it.  Only when the branch is a relaxation candidate does it become the
end of a variable-sized frag.  Branches within nomacro sections are
not relaxed in the current implementation, so we handle them just as
before.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: MIPS gas relaxation still doesn't work

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> On Tue, Oct 15, 2002 at 01:56:47PM -0700, Eric Christopher
 Daniel> wrote:
 >> > While I agree with you in theory, how would GCC handle
 >> user-written > asm("") blocks without an assemble-time jump
 >> relaxation of some sort?
 >> > 
 >> 
 >> Treat them as regions that cannot be scheduled across I believe.

 Daniel> No, I mean the problem that Maciej raised: how can we even
 Daniel> pretend to know their length?  They're a black box; we don't
 Daniel> really want to assume that long jumps are necessary over one,
 Daniel> but we don't know how big they are.

If you write them with nomacro in effect, you can...  Doesn't gcc use
the rule that the length of an asm is the length attribute defined in
the md file, multiplied by the number of statements in the asm string?
Actually, even with macros that works if the md file specifies the
longest macro expansion as its length, but that's rather pessimistic.

	paul

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 16 Oct 2002, Alexandre Oliva wrote:

> >  Too bad.  But the marking could get disabled if ".set nomacro" was on for
> > a branch, couldn't it?
> 
> Err...  Yes, indeed, this is already the case, now that I think of
> it.  Only when the branch is a relaxation candidate does it become the
> end of a variable-sized frag.  Branches within nomacro sections are
> not relaxed in the current implementation, so we handle them just as
> before.

 OK then.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On Wed, 16 Oct 2002, Paul Koning wrote:

>  Daniel> No, I mean the problem that Maciej raised: how can we even
>  Daniel> pretend to know their length?  They're a black box; we don't
>  Daniel> really want to assume that long jumps are necessary over one,
>  Daniel> but we don't know how big they are.
> 
> If you write them with nomacro in effect, you can...  Doesn't gcc use
> the rule that the length of an asm is the length attribute defined in
> the md file, multiplied by the number of statements in the asm string?

 Except that a programmer may force ".set macro" if he needs it. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

> The tough problems I've noticed so far is the small limit
>on the number of constraints, which is only ten

This should be fixed as of gcc-3.1, since you can have named operands now.
Taking an example from the gcc docs:
        asm ("cmoveq %1,%2,%[result]"
             : [result] "=r"(result)
             : "r" (test), "r"(new), "[result]"(old));

> and the unability to pass
>a machine address, as the "R" constraint, which is expected to provide the
>function, doesn't work here and the "m" and "o" ones may require a macro
>expansion. 

I'm not sure exactly what problem you are trying to report here, but I think
it is likely true that we will need new constraint codes.  Previously we didn't
need special constraint codes for asms because everyone relied on the assembler
macros for loads.  Now that we want to get people to stop using assembler
macros, we may need to add special constraint codes so that people can write
the asms that they need.

Jim

Re: MIPS gas relaxation still doesn't work

[Jim Wilson]

>  Still for "-mips2" the code is not exactly perfect:

I'm guessing that gas is only doing one pass.  When it first looks at the
first load, the nop is necessary.  When it later moves the second load into
the branch delay slot, it doesn't go back and check to see if the nop after
the first load is still necessary.  To get this perfect, we would have to
add global optimization support to gas, so that it considered all nop
insertions and branch delay slot filling all at the same time, and iterated
until it got the best code.  I think it is pointless to do this kind of
stuff in an assembler when we already have an optimizing compiler that already
has infrastructure to do this kind of stuff.

Jim

Re: MIPS gas relaxation still doesn't work

[Maciej W. Rozycki]

On 16 Oct 2002, Jim Wilson wrote:

> > The tough problems I've noticed so far is the small limit
> >on the number of constraints, which is only ten
> 
> This should be fixed as of gcc-3.1, since you can have named operands now.
> Taking an example from the gcc docs:
>         asm ("cmoveq %1,%2,%[result]"
>              : [result] "=r"(result)
>              : "r" (test), "r"(new), "[result]"(old));

 Excellent!  Please forgive me being a bit behind on recent gcc
developments, but so far I needed a stable version to debug Linux (and
previously glibc), so I stuck to 2.95.4 for MIPS (and for others, for
consistency) so far.

> > and the unability to pass
> >a machine address, as the "R" constraint, which is expected to provide the
> >function, doesn't work here and the "m" and "o" ones may require a macro
> >expansion. 
> 
> I'm not sure exactly what problem you are trying to report here, but I think
> it is likely true that we will need new constraint codes.  Previously we didn't
> need special constraint codes for asms because everyone relied on the assembler
> macros for loads.  Now that we want to get people to stop using assembler
> macros, we may need to add special constraint codes so that people can write
> the asms that they need.

 Sometimes there is a need for a machine expressable address (i.e. of the
"imm16(reg)" form), such as in the following code (a real-life example): 

static inline void set_bit(unsigned long nr, volatile void *addr)
{
	unsigned long *m = ((unsigned long *) addr) + (nr >> 6);
	unsigned long temp;

	__asm__ __volatile__(
		"1:\tlld\t%0, %1\t\t# set_bit\n\t"
		"or\t%0, %2\n\t"
		"scd\t%0, %1\n\t"
		"beqz\t%0, 1b"
		: "=&r" (temp), "=m" (*m)
		: "ir" (1UL << (nr & 0x3f)), "m" (*m)
		: "memory");
}

This works but it sucks -- if "addr" is a global variable both "lld" and
"scd" may unnecessarily expand to many instructions.  Additionally if $at
becomes unavailable, the code doesn't build.

 Currently this may be solved as follows: 

static inline void set_bit(unsigned long nr, volatile void *addr)
{
	unsigned long *m = ((unsigned long *) addr) + (nr >> 6);
	unsigned long temp, ptr;

	__asm__ __volatile__(
		".set\tpush\n\t"
		".set\tnoat\n\t"
		"dla\t%2, %4\t\t# set_bit\n\t"
		"1:\tlld\t%0, (%2)\n\t"
		"or\t%0, %3\n\t"
		"scd\t%0, (%2)\n\t"
		"beqz\t%0, 1b\n\t"
		".set\pop"
		: "=&r" (temp), "=m" (*m), "=&r" (ptr)
		: "Ir" (1UL << (nr & 0x3f)), "m" (*m)
		: "memory");
}

At least it works, but it sucks as well -- the "dla" may be unnecessary if
"addr" happens to be already loaded into one of registers or is an
automatic variable accessible e.g. with imm16($sp).

 This begs to be rewritten simply as follows:

static inline void set_bit(unsigned long nr, volatile void *addr)
{
	unsigned long *m = ((unsigned long *) addr) + (nr >> 6);
	unsigned long temp;

	__asm__ __volatile__(
		".set\tpush\n\t"
		".set\tnoat\n\t"
		"1:\tlld\t%0, %1\t\t# set_bit\n\t"
		"or\t%0, %2\n\t"
		"scd\t%0, %1\n\t"
		"beqz\t%0, 1b\n\t"
		".set\pop"
		: "=&r" (temp), "=R" (*m)
		: "Ir" (1UL << (nr & 0x3f)), "R" (*m)
		: "memory");
}

as the definition of "R" is "imm16(reg)".  This should let gcc emit any
reloads if necessary and allow the code not to worry about loading of the
address itself (which is not a subject of it).  But it often doesn't work.
If the "m" address happens to fit the "R" constraint, it works fine,
otherwise an "`asm' operand requires impossible reload" error triggers.  A
brief study of gcc I did not so long ago revealed it doesn't have any way
to deduce how to do a reload between an operand that satisfies the "m" 
constraint and an operand that satisfies the "R" one.

 There is a number of places in Linux that would benefit from working "R".

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +