* Re: MIPS gas relaxation still doesn't work [not found] ` <20021013145423.A10174@lucon.org> @ 2002-10-14 9:23 ` H. J. Lu 2002-10-14 9:35 ` Richard Sandiford 2002-10-14 9:40 ` Alexandre Oliva 0 siblings, 2 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 9:23 UTC (permalink / raw) To: aoliva, linux-mips, gcc; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 9:23 ` MIPS gas relaxation still doesn't work H. J. Lu @ 2002-10-14 9:35 ` Richard Sandiford 2002-10-14 9:37 ` H. J. Lu 2002-10-14 9:40 ` Alexandre Oliva 1 sibling, 1 reply; 53+ messages in thread From: Richard Sandiford @ 2002-10-14 9:35 UTC (permalink / raw) To: H. J. Lu; +Cc: aoliva, linux-mips, gcc, binutils "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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 9:35 ` Richard Sandiford @ 2002-10-14 9:37 ` H. J. Lu 2002-10-14 10:04 ` Richard Sandiford 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 9:37 UTC (permalink / raw) To: Richard Sandiford; +Cc: aoliva, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 9:37 ` H. J. Lu @ 2002-10-14 10:04 ` Richard Sandiford 2002-10-14 10:43 ` H. J. Lu 0 siblings, 1 reply; 53+ messages in thread From: Richard Sandiford @ 2002-10-14 10:04 UTC (permalink / raw) To: H. J. Lu; +Cc: aoliva, linux-mips, gcc, binutils "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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 10:04 ` Richard Sandiford @ 2002-10-14 10:43 ` H. J. Lu 2002-10-14 10:50 ` David S. Miller 2002-10-14 11:13 ` Alexandre Oliva 0 siblings, 2 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 10:43 UTC (permalink / raw) To: Richard Sandiford; +Cc: aoliva, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 10:43 ` H. J. Lu @ 2002-10-14 10:50 ` David S. Miller 2002-10-14 10:53 ` H. J. Lu 2002-10-14 11:13 ` Alexandre Oliva 1 sibling, 1 reply; 53+ messages in thread From: David S. Miller @ 2002-10-14 10:50 UTC (permalink / raw) To: hjl; +Cc: rsandifo, aoliva, linux-mips, gcc, binutils 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? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 10:50 ` David S. Miller @ 2002-10-14 10:53 ` H. J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 10:53 UTC (permalink / raw) To: David S. Miller; +Cc: rsandifo, aoliva, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 10:43 ` H. J. Lu 2002-10-14 10:50 ` David S. Miller @ 2002-10-14 11:13 ` Alexandre Oliva 2002-10-14 11:21 ` H. J. Lu 1 sibling, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 11:13 UTC (permalink / raw) To: H. J. Lu; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 11:13 ` Alexandre Oliva @ 2002-10-14 11:21 ` H. J. Lu 2002-10-14 12:28 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 11:21 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 11:21 ` H. J. Lu @ 2002-10-14 12:28 ` Alexandre Oliva 2002-10-14 12:37 ` H. J. Lu 0 siblings, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 12:28 UTC (permalink / raw) To: H. J. Lu; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 12:28 ` Alexandre Oliva @ 2002-10-14 12:37 ` H. J. Lu 2002-10-14 12:58 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 12:37 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 12:37 ` H. J. Lu @ 2002-10-14 12:58 ` Alexandre Oliva 2002-10-14 13:00 ` H. J. Lu 0 siblings, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 12:58 UTC (permalink / raw) To: H. J. Lu; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 12:58 ` Alexandre Oliva @ 2002-10-14 13:00 ` H. J. Lu 2002-10-14 13:08 ` David S. Miller ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 13:00 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Richard Sandiford, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 13:00 ` H. J. Lu @ 2002-10-14 13:08 ` David S. Miller 2002-10-14 13:23 ` H. J. Lu 2002-10-15 13:28 ` Jim Wilson 2002-10-15 16:54 ` Richard Henderson 2 siblings, 1 reply; 53+ messages in thread From: David S. Miller @ 2002-10-14 13:08 UTC (permalink / raw) To: hjl; +Cc: aoliva, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 13:08 ` David S. Miller @ 2002-10-14 13:23 ` H. J. Lu 2002-10-14 14:04 ` David S. Miller 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 13:23 UTC (permalink / raw) To: David S. Miller; +Cc: aoliva, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 13:23 ` H. J. Lu @ 2002-10-14 14:04 ` David S. Miller 2002-10-14 14:14 ` H. J. Lu 0 siblings, 1 reply; 53+ messages in thread From: David S. Miller @ 2002-10-14 14:04 UTC (permalink / raw) To: hjl; +Cc: aoliva, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:04 ` David S. Miller @ 2002-10-14 14:14 ` H. J. Lu 2002-10-14 14:17 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 14:14 UTC (permalink / raw) To: David S. Miller; +Cc: aoliva, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:14 ` H. J. Lu @ 2002-10-14 14:17 ` Alexandre Oliva 2002-10-14 14:18 ` H. J. Lu 2002-10-14 14:44 ` Michael Matz 0 siblings, 2 replies; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 14:17 UTC (permalink / raw) To: H. J. Lu; +Cc: David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:17 ` Alexandre Oliva @ 2002-10-14 14:18 ` H. J. Lu 2002-10-14 15:37 ` Alexandre Oliva 2002-10-14 17:02 ` Eric Christopher 2002-10-14 14:44 ` Michael Matz 1 sibling, 2 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 14:18 UTC (permalink / raw) To: Alexandre Oliva; +Cc: David S. Miller, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:18 ` H. J. Lu @ 2002-10-14 15:37 ` Alexandre Oliva 2002-10-14 15:40 ` H. J. Lu 2002-10-14 17:02 ` Eric Christopher 1 sibling, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 15:37 UTC (permalink / raw) To: H. J. Lu; +Cc: David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 15:37 ` Alexandre Oliva @ 2002-10-14 15:40 ` H. J. Lu 2002-10-15 1:08 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: H. J. Lu @ 2002-10-14 15:40 UTC (permalink / raw) To: Alexandre Oliva; +Cc: David S. Miller, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 15:40 ` H. J. Lu @ 2002-10-15 1:08 ` Alexandre Oliva 2002-10-15 2:53 ` Dominic Sweetman 2002-10-15 13:27 ` Maciej W. Rozycki 0 siblings, 2 replies; 53+ messages in thread From: Alexandre Oliva @ 2002-10-15 1:08 UTC (permalink / raw) To: H. J. Lu; +Cc: David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 1:08 ` Alexandre Oliva @ 2002-10-15 2:53 ` Dominic Sweetman 2002-10-15 8:12 ` Alexandre Oliva 2002-10-15 14:18 ` Jim Wilson 2002-10-15 13:27 ` Maciej W. Rozycki 1 sibling, 2 replies; 53+ messages in thread From: Dominic Sweetman @ 2002-10-15 2:53 UTC (permalink / raw) To: Alexandre Oliva Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils, nigel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 2:53 ` Dominic Sweetman @ 2002-10-15 8:12 ` Alexandre Oliva 2002-10-15 14:18 ` Jim Wilson 1 sibling, 0 replies; 53+ messages in thread From: Alexandre Oliva @ 2002-10-15 8:12 UTC (permalink / raw) To: Dominic Sweetman Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils, nigel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 2:53 ` Dominic Sweetman 2002-10-15 8:12 ` Alexandre Oliva @ 2002-10-15 14:18 ` Jim Wilson 1 sibling, 0 replies; 53+ messages in thread From: Jim Wilson @ 2002-10-15 14:18 UTC (permalink / raw) To: Dominic Sweetman Cc: Alexandre Oliva, H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils, nigel 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 1:08 ` Alexandre Oliva 2002-10-15 2:53 ` Dominic Sweetman @ 2002-10-15 13:27 ` Maciej W. Rozycki 2002-10-15 16:37 ` Jim Wilson 2002-10-15 18:40 ` Alexandre Oliva 1 sibling, 2 replies; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-15 13:27 UTC (permalink / raw) To: Alexandre Oliva Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 13:27 ` Maciej W. Rozycki @ 2002-10-15 16:37 ` Jim Wilson 2002-10-16 6:39 ` Maciej W. Rozycki 2002-10-15 18:40 ` Alexandre Oliva 1 sibling, 1 reply; 53+ messages in thread From: Jim Wilson @ 2002-10-15 16:37 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Alexandre Oliva, H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 16:37 ` Jim Wilson @ 2002-10-16 6:39 ` Maciej W. Rozycki 2002-10-16 10:38 ` Jim Wilson 0 siblings, 1 reply; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 6:39 UTC (permalink / raw) To: Jim Wilson Cc: Alexandre Oliva, H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 6:39 ` Maciej W. Rozycki @ 2002-10-16 10:38 ` Jim Wilson 0 siblings, 0 replies; 53+ messages in thread From: Jim Wilson @ 2002-10-16 10:38 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Alexandre Oliva, H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 13:27 ` Maciej W. Rozycki 2002-10-15 16:37 ` Jim Wilson @ 2002-10-15 18:40 ` Alexandre Oliva 2002-10-16 7:01 ` Maciej W. Rozycki 1 sibling, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-15 18:40 UTC (permalink / raw) To: Maciej W. Rozycki Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 18:40 ` Alexandre Oliva @ 2002-10-16 7:01 ` Maciej W. Rozycki 2002-10-16 7:47 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 7:01 UTC (permalink / raw) To: Alexandre Oliva Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 7:01 ` Maciej W. Rozycki @ 2002-10-16 7:47 ` Alexandre Oliva 2002-10-16 8:06 ` Maciej W. Rozycki 0 siblings, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-16 7:47 UTC (permalink / raw) To: Maciej W. Rozycki Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 7:47 ` Alexandre Oliva @ 2002-10-16 8:06 ` Maciej W. Rozycki 0 siblings, 0 replies; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 8:06 UTC (permalink / raw) To: Alexandre Oliva Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:18 ` H. J. Lu 2002-10-14 15:37 ` Alexandre Oliva @ 2002-10-14 17:02 ` Eric Christopher 2002-10-15 1:15 ` Alexandre Oliva 1 sibling, 1 reply; 53+ messages in thread From: Eric Christopher @ 2002-10-14 17:02 UTC (permalink / raw) To: H. J. Lu Cc: Alexandre Oliva, David S. Miller, rsandifo, linux-mips, gcc, binutils 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... ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 17:02 ` Eric Christopher @ 2002-10-15 1:15 ` Alexandre Oliva 0 siblings, 0 replies; 53+ messages in thread From: Alexandre Oliva @ 2002-10-15 1:15 UTC (permalink / raw) To: Eric Christopher Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 14:17 ` Alexandre Oliva 2002-10-14 14:18 ` H. J. Lu @ 2002-10-14 14:44 ` Michael Matz 1 sibling, 0 replies; 53+ messages in thread From: Michael Matz @ 2002-10-14 14:44 UTC (permalink / raw) To: Alexandre Oliva Cc: H. J. Lu, David S. Miller, rsandifo, linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 13:00 ` H. J. Lu 2002-10-14 13:08 ` David S. Miller @ 2002-10-15 13:28 ` Jim Wilson 2002-10-15 13:45 ` Paul Koning 2002-10-15 14:00 ` Daniel Jacobowitz 2002-10-15 16:54 ` Richard Henderson 2 siblings, 2 replies; 53+ messages in thread From: Jim Wilson @ 2002-10-15 13:28 UTC (permalink / raw) To: H. J. Lu; +Cc: Alexandre Oliva, Richard Sandiford, linux-mips, gcc, binutils >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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 13:28 ` Jim Wilson @ 2002-10-15 13:45 ` Paul Koning 2002-10-15 14:32 ` Maciej W. Rozycki 2002-10-15 14:00 ` Daniel Jacobowitz 1 sibling, 1 reply; 53+ messages in thread From: Paul Koning @ 2002-10-15 13:45 UTC (permalink / raw) To: wilson; +Cc: hjl, aoliva, rsandifo, linux-mips, gcc, binutils >>>>> "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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 13:45 ` Paul Koning @ 2002-10-15 14:32 ` Maciej W. Rozycki 2002-10-15 15:33 ` Alexandre Oliva 0 siblings, 1 reply; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-15 14:32 UTC (permalink / raw) To: Paul Koning; +Cc: wilson, hjl, aoliva, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 14:32 ` Maciej W. Rozycki @ 2002-10-15 15:33 ` Alexandre Oliva 2002-10-16 5:32 ` Maciej W. Rozycki 0 siblings, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-15 15:33 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Paul Koning, wilson, hjl, rsandifo, linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 15:33 ` Alexandre Oliva @ 2002-10-16 5:32 ` Maciej W. Rozycki 0 siblings, 0 replies; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 5:32 UTC (permalink / raw) To: Alexandre Oliva Cc: Paul Koning, wilson, hjl, rsandifo, linux-mips, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 13:28 ` Jim Wilson 2002-10-15 13:45 ` Paul Koning @ 2002-10-15 14:00 ` Daniel Jacobowitz 2002-10-15 14:56 ` Eric Christopher 2002-10-15 15:23 ` Jim Wilson 1 sibling, 2 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-10-15 14:00 UTC (permalink / raw) To: Jim Wilson; +Cc: gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 14:00 ` Daniel Jacobowitz @ 2002-10-15 14:56 ` Eric Christopher 2002-10-15 15:05 ` Daniel Jacobowitz 2002-10-15 15:23 ` Jim Wilson 1 sibling, 1 reply; 53+ messages in thread From: Eric Christopher @ 2002-10-15 14:56 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Jim Wilson, gcc, binutils > 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... ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 14:56 ` Eric Christopher @ 2002-10-15 15:05 ` Daniel Jacobowitz 2002-10-16 7:53 ` Paul Koning 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-10-15 15:05 UTC (permalink / raw) To: Eric Christopher; +Cc: Jim Wilson, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 15:05 ` Daniel Jacobowitz @ 2002-10-16 7:53 ` Paul Koning 2002-10-16 8:11 ` Maciej W. Rozycki 0 siblings, 1 reply; 53+ messages in thread From: Paul Koning @ 2002-10-16 7:53 UTC (permalink / raw) To: drow; +Cc: echristo, wilson, gcc, binutils >>>>> "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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 7:53 ` Paul Koning @ 2002-10-16 8:11 ` Maciej W. Rozycki 0 siblings, 0 replies; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 8:11 UTC (permalink / raw) To: Paul Koning; +Cc: drow, echristo, wilson, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 14:00 ` Daniel Jacobowitz 2002-10-15 14:56 ` Eric Christopher @ 2002-10-15 15:23 ` Jim Wilson 2002-10-16 5:38 ` Maciej W. Rozycki 1 sibling, 1 reply; 53+ messages in thread From: Jim Wilson @ 2002-10-15 15:23 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc, binutils >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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-15 15:23 ` Jim Wilson @ 2002-10-16 5:38 ` Maciej W. Rozycki 2002-10-16 10:37 ` Jim Wilson 0 siblings, 1 reply; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 5:38 UTC (permalink / raw) To: Jim Wilson; +Cc: Daniel Jacobowitz, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 5:38 ` Maciej W. Rozycki @ 2002-10-16 10:37 ` Jim Wilson 2002-10-16 11:04 ` Maciej W. Rozycki 0 siblings, 1 reply; 53+ messages in thread From: Jim Wilson @ 2002-10-16 10:37 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Daniel Jacobowitz, gcc, binutils > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-16 10:37 ` Jim Wilson @ 2002-10-16 11:04 ` Maciej W. Rozycki 0 siblings, 0 replies; 53+ messages in thread From: Maciej W. Rozycki @ 2002-10-16 11:04 UTC (permalink / raw) To: Jim Wilson; +Cc: Daniel Jacobowitz, gcc, binutils 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 + ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 13:00 ` H. J. Lu 2002-10-14 13:08 ` David S. Miller 2002-10-15 13:28 ` Jim Wilson @ 2002-10-15 16:54 ` Richard Henderson 2 siblings, 0 replies; 53+ messages in thread From: Richard Henderson @ 2002-10-15 16:54 UTC (permalink / raw) To: H. J. Lu; +Cc: Alexandre Oliva, Richard Sandiford, linux-mips, gcc, binutils 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~ ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 9:23 ` MIPS gas relaxation still doesn't work H. J. Lu 2002-10-14 9:35 ` Richard Sandiford @ 2002-10-14 9:40 ` Alexandre Oliva 2002-10-14 9:44 ` H. J. Lu 1 sibling, 1 reply; 53+ messages in thread From: Alexandre Oliva @ 2002-10-14 9:40 UTC (permalink / raw) To: H. J. Lu; +Cc: linux-mips, gcc, binutils 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MIPS gas relaxation still doesn't work 2002-10-14 9:40 ` Alexandre Oliva @ 2002-10-14 9:44 ` H. J. Lu 0 siblings, 0 replies; 53+ messages in thread From: H. J. Lu @ 2002-10-14 9:44 UTC (permalink / raw) To: Alexandre Oliva; +Cc: linux-mips, gcc, binutils 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2002-10-16 17:16 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20021012113423.A27894@lucon.org> [not found] ` <20021013145423.A10174@lucon.org> 2002-10-14 9:23 ` MIPS gas relaxation still doesn't work H. J. Lu 2002-10-14 9:35 ` Richard Sandiford 2002-10-14 9:37 ` H. J. Lu 2002-10-14 10:04 ` Richard Sandiford 2002-10-14 10:43 ` H. J. Lu 2002-10-14 10:50 ` David S. Miller 2002-10-14 10:53 ` H. J. Lu 2002-10-14 11:13 ` Alexandre Oliva 2002-10-14 11:21 ` H. J. Lu 2002-10-14 12:28 ` Alexandre Oliva 2002-10-14 12:37 ` H. J. Lu 2002-10-14 12:58 ` Alexandre Oliva 2002-10-14 13:00 ` H. J. Lu 2002-10-14 13:08 ` David S. Miller 2002-10-14 13:23 ` H. J. Lu 2002-10-14 14:04 ` David S. Miller 2002-10-14 14:14 ` H. J. Lu 2002-10-14 14:17 ` Alexandre Oliva 2002-10-14 14:18 ` H. J. Lu 2002-10-14 15:37 ` Alexandre Oliva 2002-10-14 15:40 ` H. J. Lu 2002-10-15 1:08 ` Alexandre Oliva 2002-10-15 2:53 ` Dominic Sweetman 2002-10-15 8:12 ` Alexandre Oliva 2002-10-15 14:18 ` Jim Wilson 2002-10-15 13:27 ` Maciej W. Rozycki 2002-10-15 16:37 ` Jim Wilson 2002-10-16 6:39 ` Maciej W. Rozycki 2002-10-16 10:38 ` Jim Wilson 2002-10-15 18:40 ` Alexandre Oliva 2002-10-16 7:01 ` Maciej W. Rozycki 2002-10-16 7:47 ` Alexandre Oliva 2002-10-16 8:06 ` Maciej W. Rozycki 2002-10-14 17:02 ` Eric Christopher 2002-10-15 1:15 ` Alexandre Oliva 2002-10-14 14:44 ` Michael Matz 2002-10-15 13:28 ` Jim Wilson 2002-10-15 13:45 ` Paul Koning 2002-10-15 14:32 ` Maciej W. Rozycki 2002-10-15 15:33 ` Alexandre Oliva 2002-10-16 5:32 ` Maciej W. Rozycki 2002-10-15 14:00 ` Daniel Jacobowitz 2002-10-15 14:56 ` Eric Christopher 2002-10-15 15:05 ` Daniel Jacobowitz 2002-10-16 7:53 ` Paul Koning 2002-10-16 8:11 ` Maciej W. Rozycki 2002-10-15 15:23 ` Jim Wilson 2002-10-16 5:38 ` Maciej W. Rozycki 2002-10-16 10:37 ` Jim Wilson 2002-10-16 11:04 ` Maciej W. Rozycki 2002-10-15 16:54 ` Richard Henderson 2002-10-14 9:40 ` Alexandre Oliva 2002-10-14 9:44 ` H. J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).