vax optimization breakage?

vax optimization breakage?

[Brandon Creighton]

Hello.  

The following test code is compiled incorrectly by gcc (both in-tree
gcc and recent snapshots) at -O2.  Details follow.  I have observed 
this behavior with the following configurations:
(i386-unknown-openbsd2.7 x vax-unknown-openbsd2.7)
(i386-unknown-openbsd2.7 x vax-unknown-ultrix)
vax-unknown-openbsd2.7 (native)
(i686-pc-linux-gnu x vax-unknown-openbsd2.7)


int cnt;
void
func()
{
	int i;

	cnt = 0;
	for (i = 0; i<5; i++) {
		cnt++;
	}
}


The code that is generated looks like this:

#NO_APP
gcc2_compiled.:
___gnu_compiled_c:
.text
        .align 1
.globl _func
        .type   _func , @function
_func:
        .word 0x0
        clrl _cnt
        clrl r0
L5:
        incl r0
        cmpl r0,$4
        jleq L5
        ret
        .size   _func , . - _func
.comm _cnt,4 


_cnt is ending up unchanged.  

(speculation begins here, please don't flame too badly)
I've looked through rtl dumps, and it looks like the "set" insn which 
sets cnt to what it should be (after the loop) gets trapped with 
a code_label with 0 uses:

(jump_insn 16 45 17 (return) -1 (nil)
    (nil))

(barrier 17 16 34)

(note 34 17 56 NOTE_INSN_LOOP_END -1347440721)

(code_label 56 34 58 7 "" "" [0 uses])

(insn 58 56 37 (set (mem/f:SI (symbol_ref:SI ("cnt")) 4)
        (reg/v:SI 23)) -1 (nil)
    (nil))

(note 37 58 0 0x40349580 NOTE_INSN_BLOCK_END -1347440721)

This code_label and the set insn soon get removed erroneously, since the 
"return" pattern for the vax just outputs a single instruction and has no
qualifying statements.  Looking around, I see that vax is the only 
architecture which has such a simple return insn pattern and is not 
completely disabled in the configure script.  Everything else seems to 
at the very least check reload_completed.

I made the vax's return pattern check reload_completed as well, but that 
wasn't enough; other "ret" instructions weren't being output when they 
should have been, so lots of other things were breaking.  To fix that problem,
I added an "epilogue" expansion which just expanded to (return).  So far,
that has given me passable results at -O0, -O1, and -O2.. but it seems
like an awful dirty hack.  Could anyone shed some light?

thanks
bjc@pobox.com

Re: vax optimization breakage?

[Jeffrey A Law]

  In message < 20000719004847.A12@pobox.com >you write:
  > The code that is generated looks like this:
  > 
  > #NO_APP
  > gcc2_compiled.:
  > ___gnu_compiled_c:
  > .text
  >         .align 1
  > .globl _func
  >         .type   _func , @function
  > _func:
  >         .word 0x0
  >         clrl _cnt
  >         clrl r0
  > L5:
  >         incl r0
  >         cmpl r0,$4
  >         jleq L5
  >         ret
  >         .size   _func , . - _func
  > .comm _cnt,4 
  > 
  > 
  > _cnt is ending up unchanged.  
  > 
  > (speculation begins here, please don't flame too badly)
  > I've looked through rtl dumps, and it looks like the "set" insn which 
  > sets cnt to what it should be (after the loop) gets trapped with 
  > a code_label with 0 uses:  > 

What we really need to see are the .gcse and .loop dump files so that we
can determine if things look OK before the loop optimizer or after the
loop optimizer.  One we have that information we can guide you towards
the offending code.

jeff

Re: vax optimization breakage?

[Brandon Creighton]

On Sun, Jul 23, 2000 at 01:28:52PM -0600, Jeffrey A Law wrote:
 
> What we really need to see are the .gcse and .loop dump files so that we
> can determine if things look OK before the loop optimizer or after the
> loop optimizer.  One we have that information we can guide you towards
> the offending code.

Sorry, I should have included them in my first message.  Attached are .gcse,
.loop, and .cse2.

Re: vax optimization breakage?

[Jeffrey A Law]

  In message < 20000723172324.D17424@pobox.com >you write:
  > 
  > --XMCwj5IQnwKtuyBG
  > Content-Type: text/plain; charset=us-ascii
  > 
  > On Sun, Jul 23, 2000 at 01:28:52PM -0600, Jeffrey A Law wrote:
  >  
  > > What we really need to see are the .gcse and .loop dump files so that we
  > > can determine if things look OK before the loop optimizer or after the
  > > loop optimizer.  One we have that information we can guide you towards
  > > the offending code.
  > 
  > Sorry, I should have included them in my first message.  Attached are .gcse
  > ,
  > .loop, and .cse2.
I think the return insn was inserted into the wrong place.  It really
shouldn't have been inserted inside the loop notes, but instead should
have been placed after the LOOP_END note.


What do the .rtl and .jump rtl dumps look like?

jeff

Re: vax optimization breakage?

[Brandon Creighton]

On Sun, Jul 23, 2000 at 04:14:52PM -0600, Jeffrey A Law wrote:

> I think the return insn was inserted into the wrong place.  It really
> shouldn't have been inserted inside the loop notes, but instead should
> have been placed after the LOOP_END note.
> 
> 
> What do the .rtl and .jump rtl dumps look like?

attached.

Re: vax optimization breakage?

[Jeffrey A Law]

  In message < 20000723181116.E17424@pobox.com >you write:
  > 
  > --3Pql8miugIZX0722
  > Content-Type: text/plain; charset=us-ascii
  > 
  > On Sun, Jul 23, 2000 at 04:14:52PM -0600, Jeffrey A Law wrote:
  > 
  > > I think the return insn was inserted into the wrong place.  It really
  > > shouldn't have been inserted inside the loop notes, but instead should
  > > have been placed after the LOOP_END note.
  > > 
  > > 
  > > What do the .rtl and .jump rtl dumps look like?
  > 
  > attached.
Thanks.  The problem is the jump optimizer is turning jump_insn 16 into
a RETURN.

You should try debugging jump.c to see when that happens.  You might start
by seeing if redirect_jump or redirect_exp is the culprit.
  

jeff

Re: vax optimization breakage?

[Richard Henderson]

On Sun, Jul 23, 2000 at 06:00:33PM -0600, Jeffrey A Law wrote:
> Thanks.  The problem is the jump optimizer is turning jump_insn 16 into
> a RETURN.

No, that's all kosher.  jump is allowed to make that transformation
any time HAVE_return is true.  Which for VAX is always.

The problem is that the LOOP_END note somehow fell below the
return insn.  This happens in .01.sibling, so presumably it
happened when running find_basic_blocks.  Anyway, the result
is that loop emits the cleanup code after the return, which
of course gets removed as dead code.


r~

Re: vax optimization breakage?

[Jeffrey A Law]

  In message < 20000727015020.A26441@cygnus.com >you write:
  > On Sun, Jul 23, 2000 at 06:00:33PM -0600, Jeffrey A Law wrote:
  > > Thanks.  The problem is the jump optimizer is turning jump_insn 16 into
  > > a RETURN.
  > 
  > No, that's all kosher.  jump is allowed to make that transformation
  > any time HAVE_return is true.  Which for VAX is always.
  > 
  > The problem is that the LOOP_END note somehow fell below the
  > return insn.  This happens in .01.sibling, so presumably it
  > happened when running find_basic_blocks.  Anyway, the result
  > is that loop emits the cleanup code after the return, which
  > of course gets removed as dead code.
I forgot about .01.sibling :-) 

jeff