Re: Alias code

Re: Alias code

[Franz Sirl]

Am Mon, 29 Jun 1998 schrieb Jeffrey A Law:
>In message <199806291730.KAA16121@cygnus.com>you write:
>  > At 12:18 29.06.98 , Jeffrey A Law wrote:
>  > >
>  > >We've got a little problem.
>  > >
>  > >While the machine independent code is mostly free of gen_rtx (MEM)
>  > >calls, many of the target files, and some of the front-ends that we 
>  > >want to interoperate (but possibly do not control) with are not free
>  > >of such calls.
>  > 
>  > Jeff, if you want to see that changed everywhere, why don't you simply put
>  > a request for patches on the list like for the warning patches? The changes
>  > are very simple (I even remember sending you a sed script doing most of the
>  > work), so nearly everyone can do it.
>Folks should certainly feel free to submit these changes.  I certainly
>would like to see this fixed throughout the compiler.  Posting the
>sed script again would probably encourage this :-)

So here is this supersimple script again ;-). I've done it for the rs6000
backend and it catches most gen_rtx in there. Only the gen_rtx(GET_CODE...)
cases are missing, since I don't know what to do there. Eventually people
without FSF assignement like me have to split the patches into more parts to
avoid the assignement.

Franz.

#!/bin/sh

sed -e "s/gen_rtx (COMPARE, /gen_rtx_COMPARE (/" <$1 |\
sed -e "s/gen_rtx (MEM, /gen_rtx_MEM (/" |\
sed -e "s/gen_rtx (REG, /gen_rtx_REG (/" |\
sed -e "s/gen_rtx (PLUS, /gen_rtx_PLUS (/" |\
sed -e "s/gen_rtx (USE, /gen_rtx_USE (/" |\
sed -e "s/gen_rtx (SYMBOL_REF, /gen_rtx_SYMBOL_REF (/" |\
sed -e "s/gen_rtx (EXPR_LIST, /gen_rtx_EXPR_LIST (/" |\
sed -e "s/gen_rtx (IF_THEN_ELSE, /gen_rtx_IF_THEN_ELSE (/" |\
sed -e "s/gen_rtx (SET, /gen_rtx_SET (/" |\
sed -e "s/gen_rtx (PARALLEL, /gen_rtx_PARALLEL (/" |\
sed -e "s/gen_rtx (NE, /gen_rtx_NE (/" |\
sed -e "s/gen_rtx (LABEL_REF, /gen_rtx_LABEL_REF (/" |\
sed -e "s/gen_rtx (CONST_INT, /gen_rtx_CONST_INT (/" |\
sed -e "s/gen_rtx (SUBREG, /gen_rtx_SUBREG (/" |\
sed -e "s/gen_rtx (INSN_LIST, /gen_rtx_INSN_LIST (/" |\
sed -e "s/gen_rtx (CLOBBER, /gen_rtx_CLOBBER (/" |\
sed -e "s/gen_rtx (SCRATCH, /gen_rtx_SCRATCH (/" |\
sed -e "s/gen_rtx.(LO_SUM,./gen_rtx_LO_SUM (/" >$1.new

Re: Alias code

[David Edelsohn]

	I already have this substitution done for rs6000 included with
some other fixes that I am working on.

David

Re: Alias code

[Mike Stump]

> Date: Mon, 29 Jun 1998 04:18:30 -0600
> From: Jeffrey A Law <law@cygnus.com>

> We've got a little problem.

> While the machine independent code is mostly free of gen_rtx (MEM)
> calls, many of the target files, and some of the front-ends that we 
> want to interoperate (but possibly do not control) with are not free
> of such calls.

> Thoughts?

Sigh, not sure what to say other than it would be nice if someone
worked to get major api type things like this that are simple into
gcc2.  Then all code can do it, and we'd have fewer problems.

Re: Alias code

[Jeffrey A Law]

  In message < 199807010045.RAA12576@kankakee.wrs.com >you write:
  > > Date: Mon, 29 Jun 1998 04:18:30 -0600
  > > From: Jeffrey A Law <law@cygnus.com>
  > 
  > > We've got a little problem.
  > 
  > > While the machine independent code is mostly free of gen_rtx (MEM)
  > > calls, many of the target files, and some of the front-ends that we 
  > > want to interoperate (but possibly do not control) with are not free
  > > of such calls.
  > 
  > > Thoughts?
  > 
  > Sigh, not sure what to say other than it would be nice if someone
  > worked to get major api type things like this that are simple into
  > gcc2.  Then all code can do it, and we'd have fewer problems.
That still wouldn't resolve how to deal with ports and front-ends
that aren't in the gcc2 or egcs source trees.

jeff

Re: Alias code

[Jeffrey A Law]

  In message <199806291730.KAA16121@cygnus.com>you write:
  > At 12:18 29.06.98 , Jeffrey A Law wrote:
  > >
  > >We've got a little problem.
  > >
  > >While the machine independent code is mostly free of gen_rtx (MEM)
  > >calls, many of the target files, and some of the front-ends that we 
  > >want to interoperate (but possibly do not control) with are not free
  > >of such calls.
  > 
  > Jeff, if you want to see that changed everywhere, why don't you simply put
  > a request for patches on the list like for the warning patches? The changes
  > are very simple (I even remember sending you a sed script doing most of the
  > work), so nearly everyone can do it.
Folks should certainly feel free to submit these changes.  I certainly
would like to see this fixed throughout the compiler.  Posting the
sed script again would probably encourage this :-)


However, there are still backends which we can not convert because they
are not part of egcs (for example the tic30/c40 ports which Michael
Hayes is working on) or front-ends which we can't convert yet (Pascal,
Ada, Modula3 immediately come to mind).  Thus we have to avoid breaking
those hunks of code with the alias set changes.

Mark's submitted & I've approved a fix for these problems.

jeff

Re: Alias code

[Michael P. Hayes]

Jeffrey A Law writes:

 > However, there are still backends which we can not convert because they
 > are not part of egcs (for example the tic30/c40 ports which Michael
 > Hayes is working on) or front-ends which we can't convert yet (Pascal,
 > Ada, Modula3 immediately come to mind).  Thus we have to avoid breaking
 > those hunks of code with the alias set changes.

Don't worry about breaking the C30/C40 port.  There's not much left to do
to slot it into EGCS.  There are some more important patches for reorg
that I've got to submit to get things up and running with EGCS.

While on the alias code subject, EGCS could do with a mechanism so
that a programmer can hint to the compiler that a memory reference is
to a different address space, say an internal memory block.  The
backend could then do a better scheduling job by knowing that the
memory access is likely to be faster than normal and that it won't
conflict with an external memory access.  Any ideas?

Michael.

Re: Alias code

[Joern Rennecke]

> While on the alias code subject, EGCS could do with a mechanism so
> that a programmer can hint to the compiler that a memory reference is
> to a different address space, say an internal memory block.  The
> backend could then do a better scheduling job by knowing that the
> memory access is likely to be faster than normal and that it won't
> conflict with an external memory access.  Any ideas?

We'd need yet another field in the MEM to represent that.

Well, if we have that, then the md file can describe the stuff to the
scheduler by claiming to use different function units depending on
the address space.

Re: Alias code

[Michael P. Hayes]

Joern Rennecke writes:
 > > While on the alias code subject, EGCS could do with a mechanism so
 > > that a programmer can hint to the compiler that a memory reference is
 > > to a different address space, say an internal memory block.  The
 > > backend could then do a better scheduling job by knowing that the
 > > memory access is likely to be faster than normal and that it won't
 > > conflict with an external memory access.  Any ideas?
 > 
 > We'd need yet another field in the MEM to represent that.

Yes, but how would we inform the front-end to set this flag?  Ideally,
C needs another qualifer like fast or internal to say that a pointer
is likely to be referring to something in internal memory.  It
probably should be more general to deal with processors, in particular
DSPs, that have multiple address spaces that the compiler needs to be
aware of when generating fast code.  Does anyone know how the SHARC
port deals with this?

 > Well, if we have that, then the md file can describe the stuff to the
 > scheduler by claiming to use different function units depending on
 > the address space.

Yes, that's one aspect I was thinking of.  I was also hoping to use
the flag during RTL generation.

Michael.

Re: Alias code

[Michael Meissner]

| We've got a little problem.
|
| While the machine independent code is mostly free of gen_rtx (MEM)
| calls, many of the target files, and some of the front-ends that we 
| want to interoperate (but possibly do not control) with are not free
| of such calls.
|
| I think we need to handle these cases in a clean manner.  ie, we
| have to initialize the alias set field when we allocate the MEM or
| REG expression

We could always have the generic gen_rtx complain when it builds a MEM,
possibly under flag/ifdef control.

| Thoughts?
|
| jeff
|
| ps.  i just spent 3hrs tracking down a case where the compiler would
| mis-compile a testcase, but not if you turned on -g or certain debug
| dumps -- it was tracked down to a call to gen_rtx (MEM) in a target
| config file.  I don't want to have to do this very often :(
|
|
|
|

Alias code

[Jeffrey A Law]

We've got a little problem.

While the machine independent code is mostly free of gen_rtx (MEM)
calls, many of the target files, and some of the front-ends that we 
want to interoperate (but possibly do not control) with are not free
of such calls.

I think we need to handle these cases in a clean manner.  ie, we
have to initialize the alias set field when we allocate the MEM or
REG expression

Thoughts?

jeff

ps.  i just spent 3hrs tracking down a case where the compiler would
mis-compile a testcase, but not if you turned on -g or certain debug
dumps -- it was tracked down to a call to gen_rtx (MEM) in a target
config file.  I don't want to have to do this very often :(

Re: Alias code

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

    Jeffrey> ps.  i just spent 3hrs tracking down a case where the
    Jeffrey> compiler would mis-compile a testcase, but not if you
    Jeffrey> turned on -g or certain debug dumps -- it was tracked
    Jeffrey> down to a call to gen_rtx (MEM) in a target config file.
    Jeffrey> I don't want to have to do this very often :(

Right.  I thought of this problem, and had meant to do something about
it, but forgot.  I apologize profusely for wasting your time.

I think the only thing we can do is modify gen_rtx to special case
MEM.  BTW, configuring with --enable-checking and compiling with
-fno-strict-aliasing might help; the type-based aliasing code will
then abort if there's ever a MEM that is *not* in alias set zero.

How about this patch?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Mon Jun 29 08:45:08 1998  Mark Mitchell  <mark@markmitchell.com>

	* rtl.h: Update comment about special gen_rtx variants.
	* emit-rtl.c (gen_rtx): Handle MEMs using gen_rtx_MEM.

Index: rtl.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/rtl.h,v
retrieving revision 1.39
diff -c -p -r1.39 rtl.h
*** rtl.h	1998/06/27 15:51:48	1.39
--- rtl.h	1998/06/29 15:42:44
*************** extern rtx static_chain_incoming_rtx;
*** 1070,1076 ****
  
  /* There are some RTL codes that require special attention; the
     generation functions included above do the raw handling.  If you
!    add to this list, modify special_rtx in gengenrtl.c as well.  */
  
  extern rtx gen_rtx_CONST_INT PROTO((enum machine_mode, HOST_WIDE_INT));
  extern rtx gen_rtx_REG PROTO((enum machine_mode, int));
--- 1070,1077 ----
  
  /* There are some RTL codes that require special attention; the
     generation functions included above do the raw handling.  If you
!    add to this list, modify special_rtx in gengenrtl.c as well.  You
!    should also modify gen_rtx to use the special function.  */
  
  extern rtx gen_rtx_CONST_INT PROTO((enum machine_mode, HOST_WIDE_INT));
  extern rtx gen_rtx_REG PROTO((enum machine_mode, int));
Index: emit-rtl.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/emit-rtl.c,v
retrieving revision 1.30
diff -c -p -r1.30 emit-rtl.c
*** emit-rtl.c	1998/06/25 15:14:34	1.30
--- emit-rtl.c	1998/06/29 15:42:53
*************** gen_rtx VPROTO((enum rtx_code code, enum
*** 365,370 ****
--- 365,372 ----
      rt_val = gen_rtx_CONST_INT (mode, va_arg (p, HOST_WIDE_INT));
    else if (code == REG)
      rt_val = gen_rtx_REG (mode, va_arg (p, int));
+   else if (code == MEM)
+     rt_val = gen_rtx_MEM (mode, va_arg (p, rtx));
    else
      {
        rt_val = rtx_alloc (code);	/* Allocate the storage space.  */

Re: Alias code

[Jeffrey A Law]

  In message < 199806291545.IAA01665@smtp.earthlink.net >you write:

  > Right.  I thought of this problem, and had meant to do something about
  > it, but forgot.  I apologize profusely for wasting your time.
Don't worry about it.  The mad ramblings of a sleep deprived man :-)

I was determined to pin the problem on something from the merge and it
didn't even occur to me that it could have been the alias code -- especially
since I wasn't using -fstrict-aliasing.

One more thought -- we might want to check flag_strict_aliasing in
DIFFERENT_ALIAS_SETS_P.  It shouldn't matter after your patch, but
I don't think it hurts in any significant way.

  > I think the only thing we can do is modify gen_rtx to special case
  > MEM.  BTW, configuring with --enable-checking and compiling with
  > -fno-strict-aliasing might help; the type-based aliasing code will
  > then abort if there's ever a MEM that is *not* in alias set zero.
Right.  It probably would have caught this case (unless it changed
memory layout enough -- though it's likely we would have triggered a
fault somewhere else.

Once I had zero'd in on the alias code it was pretty trivial to find
out what had gone wrong :-)


  > How about this patch?
  > 
  > -- 
  > Mark Mitchell 			mark@markmitchell.com
  > Mark Mitchell Consulting	http://www.markmitchell.com
  > 
  > Mon Jun 29 08:45:08 1998  Mark Mitchell  <mark@markmitchell.com>
  > 
  > 	* rtl.h: Update comment about special gen_rtx variants.
  > 	* emit-rtl.c (gen_rtx): Handle MEMs using gen_rtx_MEM.
Looks good.  Presumably we've defined gen_rtx (MEM) and gen_rtx_MEM
as explicitly unable to set the alias set.  That has to be done on
the return value from those functions.  Right?



Jeff

Re: Alias code

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

    Jeffrey> One more thought -- we might want to check
    Jeffrey> flag_strict_aliasing in DIFFERENT_ALIAS_SETS_P.  It
    Jeffrey> shouldn't matter after your patch, but I don't think it
    Jeffrey> hurts in any significant way.

I don't have a strong feeling about this.  I think it amounts to
activating the CHECK_ALIAS_SETS_FOR_CONSISTENCY macro that is
presently only on with --enable-checking.  If you want to enable that
all the time, it's fine with me; it should be only a small overhead
per use of DIFFERENT_ALIAS_SETS_P.

    Jeffrey> Looks good.  Presumably we've defined gen_rtx (MEM) and
    Jeffrey> gen_rtx_MEM as explicitly unable to set the alias set.
    Jeffrey> That has to be done on the return value from those
    Jeffrey> functions.  Right?

Right.  These functions still take only one argument (the address for
the MEM), but explicitly set the MEM_ALIAS_SET to zero before
returning.  It's up to the caller to change the value, if desired.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: Alias code

[Jeffrey A Law]

  In message < 199806291649.JAA01822@smtp.earthlink.net >you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >     Jeffrey> One more thought -- we might want to check
  >     Jeffrey> flag_strict_aliasing in DIFFERENT_ALIAS_SETS_P.  It
  >     Jeffrey> shouldn't matter after your patch, but I don't think it
  >     Jeffrey> hurts in any significant way.
  > 
  > I don't have a strong feeling about this.  I think it amounts to
  > activating the CHECK_ALIAS_SETS_FOR_CONSISTENCY macro that is
  > presently only on with --enable-checking.  If you want to enable that
  > all the time, it's fine with me; it should be only a small overhead
  > per use of DIFFERENT_ALIAS_SETS_P.
It was just a thought, I don't feel particularly strongly about it.

jeff

Re: Alias code

[Franz Sirl]

At 12:18 29.06.98 , Jeffrey A Law wrote:
>
>We've got a little problem.
>
>While the machine independent code is mostly free of gen_rtx (MEM)
>calls, many of the target files, and some of the front-ends that we 
>want to interoperate (but possibly do not control) with are not free
>of such calls.

Jeff, if you want to see that changed everywhere, why don't you simply put
a request for patches on the list like for the warning patches? The changes
are very simple (I even remember sending you a sed script doing most of the
work), so nearly everyone can do it.

Franz.