basic block reordering + java

basic block reordering + java

[Anthony Green]

With basic block reordering, we often see code from gcj that ends in...

.L20:
        call    _Jv_ThrowNullPointerException
.L21:
        call    _Jv_ThrowNullPointerException
.L22:
        call    _Jv_ThrowNullPointerException
.L23:
        call    _Jv_ThrowNullPointerException
.L24:
        call    _Jv_ThrowNullPointerException
.L25:
        call    _Jv_ThrowNullPointerException
.L26:
        call    _Jv_ThrowNullPointerException

Is there an easy way for GCC to merge identical blocks?


Also, I find that if the last NullPointerException branch is taken,
printStackTrace() will produce incorrect results.  You end up seeing the
function after this in place of the one calling _Jv_ThrowNullPointerException.
Should we be backing up the program counter somewhere? (or emitting a NOP at
the very end of each function?)

AG

basic block reordering + java

[Andrew Haley]

Anthony Green writes:
 > 
 > Also, I find that if the last NullPointerException branch is taken,
 > printStackTrace() will produce incorrect results.  You end up seeing the
 > function after this in place of the one calling _Jv_ThrowNullPointerException.
 > Should we be backing up the program counter somewhere? (or emitting a NOP at
 > the very end of each function?)

We use backtrace() from glibc.  If it's wrong, this is a glibc bug.

Andrew.

Re: basic block reordering + java

[Jakub Jelinek]

On Fri, Sep 21, 2001 at 03:30:09PM +0100, Andrew Haley wrote:
> Anthony Green writes:
>  > 
>  > Also, I find that if the last NullPointerException branch is taken,
>  > printStackTrace() will produce incorrect results.  You end up seeing the
>  > function after this in place of the one calling _Jv_ThrowNullPointerException.
>  > Should we be backing up the program counter somewhere? (or emitting a NOP at
>  > the very end of each function?)
> 
> We use backtrace() from glibc.  If it's wrong, this is a glibc bug.

Note that with tail call optimization some routines can be skipped in the
backtrace. I don't know if this is the case here, but I thought I'd mention
this...

	Jakub

Re: basic block reordering + java

[Andrew Haley]

Jakub Jelinek writes:
 > On Fri, Sep 21, 2001 at 03:30:09PM +0100, Andrew Haley wrote:
 > > Anthony Green writes:
 > >  > 
 > >  > Also, I find that if the last NullPointerException branch is taken,
 > >  > printStackTrace() will produce incorrect results.  You end up seeing the
 > >  > function after this in place of the one calling _Jv_ThrowNullPointerException.
 > >  > Should we be backing up the program counter somewhere? (or emitting a NOP at
 > >  > the very end of each function?)
 > > 
 > > We use backtrace() from glibc.  If it's wrong, this is a glibc bug.
 > 
 > Note that with tail call optimization some routines can be skipped in the
 > backtrace. I don't know if this is the case here,

It's not exactly that: it's that throw() is a noreturn function so
there are no insns after "call throw".  when throw() calls backtrace()
the return pc points after the last insn in the fuction that called
throw().

Andrew.

Re: basic block reordering + java

[Jan Hubicka]

> With basic block reordering, we often see code from gcj that ends in...
> 
> .L20:
>         call    _Jv_ThrowNullPointerException
> .L21:
>         call    _Jv_ThrowNullPointerException
> .L22:
>         call    _Jv_ThrowNullPointerException
> .L23:
>         call    _Jv_ThrowNullPointerException
> .L24:
>         call    _Jv_ThrowNullPointerException
> .L25:
>         call    _Jv_ThrowNullPointerException
> .L26:
>         call    _Jv_ThrowNullPointerException
> 
> Is there an easy way for GCC to merge identical blocks?
Oh yes, all you need is to modify crossjumping to add fake "noreturn"
edges and crossjump over them.
I can try to get that working later, but right now I am quite busy by other
thinks.

Honza

Re: basic block reordering + java

[Jan Hubicka]

> > With basic block reordering, we often see code from gcj that ends in...
> > 
> > .L20:
> >         call    _Jv_ThrowNullPointerException
> > .L21:
> >         call    _Jv_ThrowNullPointerException
> > .L22:
> >         call    _Jv_ThrowNullPointerException
> > .L23:
> >         call    _Jv_ThrowNullPointerException
> > .L24:
> >         call    _Jv_ThrowNullPointerException
> > .L25:
> >         call    _Jv_ThrowNullPointerException
> > .L26:
> >         call    _Jv_ThrowNullPointerException
> > 
> > Is there an easy way for GCC to merge identical blocks?
> Oh yes, all you need is to modify crossjumping to add fake "noreturn"
> edges and crossjump over them.
> I can try to get that working later, but right now I am quite busy by other
> thinks.
Done.

Hi,

this patch adds support for crossjumping of noreturn calls.
For instance in:

int a,b;
main()
{
  if (a)
    abort ();
  if (b)
    abort ();
}
Only single abort call is emit now.

Bootstrapped/regtested i386

Sat Sep 22 17:08:26 CEST 2001  Jan Hubicka  <jh@suse.cz>
	* cfgcleanup.c (try_optimize_cfg): Add fake exit edges for noreturn
	calls when crossjumping.

*** /p2/cfg9/egcs/gcc/cfgcleanup.c	Thu Sep 20 18:33:13 2001
--- cfgcleanup.c	Sat Sep 22 14:19:55 2001
*************** try_optimize_cfg (mode)
*** 1032,1037 ****
--- 1027,1035 ----
    bool changed;
    int iterations = 0;
  
+   if (mode & CLEANUP_CROSSJUMP)
+     add_noreturn_fake_exit_edges ();
+ 
    /* Attempt to merge blocks as made possible by edge removal.  If a block
       has only one successor, and the successor has only one predecessor,
       they may be combined.  */
*************** try_optimize_cfg (mode)
*** 1162,1167 ****
--- 1160,1169 ----
        changed_overall |= changed;
      }
    while (changed);
+ 
+   if (mode & CLEANUP_CROSSJUMP)
+     remove_fake_edges ();
+ 
    return changed_overall;
  }
  \f

Re: basic block reordering + java

[Richard Henderson]

On Mon, Sep 24, 2001 at 01:49:40PM +0200, Jan Hubicka wrote:
> 	* cfgcleanup.c (try_optimize_cfg): Add fake exit edges for noreturn
> 	calls when crossjumping.

Ok.


r~