Re: Alias code

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 - how does the SHARC do it..

[Alan Lehotsky]

As to how the sharc handles the two memory spaces, the simple answer is

	BADLY.

:-)

The expanded answer is that we have added two attributes (parsed like
volatile),

	__DM__
	__PM__

that indicate which address space a pointer reference accesses.  This is
important
on the SHARC for two reasons:

	1/ parallelism.  The DSP can do TWO memory operations (fetch or store)
		in one instruction, one on each of the PM and DM busses.

	2/ address space and speed.  The PM bus is a 24 bit address bus and can
access
	 	fast on-chip memory, while the DM bus is a full 32 bit address and
can be
		off-chip (and I think on-chip too).

The attributes are used to set the size of accesses to DMmode or PMmode (which
requires a LOT of modifications to the front end where there are too many
simplifications using the Pmode #defined value.

The PMmode vs. DMmode is also used to control register allocation, such
that the
correct DAG registers are allocated for different kinds of pointers, viz.

		int PM *p;		// Candidate for DAG 2 registers (24 bits) because it
						// accesses PM data

		static char DM c;	// data word allocated in DM memory (which is
the default
							// for static data anyway...


I've left out a lot of the grody details, including extra code in reload
to handle indexed addressing and some of the horrible problems that occur when
we encounter postmodify addressing and don't have reload registers

I'm not happy with the "mode" approach, but it is the simplest way to keep the
PM/DM distinction correctly propagated thru all the compiler optimization
passes.

-- Al Lehotsky




At 12:23 AM +0000 7/1/98, Michael P. Hayes wrote:

* 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?
*


------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

Re: Alias code - how does the SHARC do it..

[Michael P. Hayes]

Alan Lehotsky writes:

 > The expanded answer is that we have added two attributes (parsed like
 > volatile),
 > 
 > 	__DM__
 > 	__PM__
 > 
 > that indicate which address space a pointer reference accesses.  This is
 > important

Ideally, I'd envisage __DM__ and __PM__ to be macros for a more
generic mechanism, like function attributes.

 > The attributes are used to set the size of accesses to DMmode or PMmode (which
 > requires a LOT of modifications to the front end where there are too many
 > simplifications using the Pmode #defined value.

IMO, Pmode should be distinct from SImode or whatever it is set to.
With the C4x backend I could emit better RTL knowing that a Pmode mode
is requested, rather than using an integer mode.

 > I'm not happy with the "mode" approach, but it is the simplest way
 > to keep the PM/DM distinction correctly propagated thru all the
 > compiler optimization passes.

Did you just try tagging MEMs instead of using separate modes?

It's a shame that the AD GCC targets have gone out of a limb from the
mainstream stuff.  Do you ever envisage the SHARC port being
incorporated into the mainstream?  I imagine there are many potential
DSP optimisations that would be of mutual benefit.

Michael.

Re: Alias code - how does the SHARC do it..

[Alan Lehotsky]

Michael Hayes writes:
> 
> Alan Lehotsky writes:
> 
>  > The expanded answer is that we have added two attributes (parsed like
>  > volatile),
>  > 
>  > 	__DM__
>  > 	__PM__
>  > 
>  > that indicate which address space a pointer reference accesses.  This is
>  > important
> 
> Ideally, I'd envisage __DM__ and __PM__ to be macros for a more
> generic mechanism, like function attributes.
> 

	Yes, except that attributes (if I understand correctly) go
	after the declaration in the GCC extension, and we want to
	express things like:

		static int PM * DM ptr;

	which says "ptr" is stored in DM, and addresses integers
	stored in PM memory.


>  > The attributes are used to set the size of accesses to DMmode or PMmode (which
>  > requires a LOT of modifications to the front end where there are too many
>  > simplifications using the Pmode #defined value.
> 
> IMO, Pmode should be distinct from SImode or whatever it is set to.
> With the C4x backend I could emit better RTL knowing that a Pmode mode
> is requested, rather than using an integer mode.
> 

	Well, you can do that by adding another mode.  The
	front-end isn't good about having a distinct mode for stack
	references - I think it uses Pmode for this too....


>  > I'm not happy with the "mode" approach, but it is the simplest way
>  > to keep the PM/DM distinction correctly propagated thru all the
>  > compiler optimization passes.
> 
> Did you just try tagging MEMs instead of using separate modes?
> 

	That won't work.  Address arithmetic is sensitive to the
	PM/DM distinction (24 vs 32 bits, remember!)  And, there
	are a lot of places that copy flags from MEM to MEM that
	would have to be modified to remember to copy this flag too!


> It's a shame that the AD GCC targets have gone out of a limb from the
> mainstream stuff.  Do you ever envisage the SHARC port being
> incorporated into the mainstream?  I imagine there are many potential
> DSP optimisations that would be of mutual benefit.
> 

	If I could figure out how to get it into an acceptable form
	for reinclusion I'd LOVE to put it back.  The problem is that
	ADI scattered the PM/DM code liberally throughout the 2.3.3
	sources, and I've only compounded the problem with my support
	for 8 bit bytes on a word-addressed machine.

	The significant DSP optimizations that are in the SHARC port are
	somewhat machine-dependent

		- Hardware loop support (we extended loop support to
		  better handle HW loops - but that would not be too
		  horrible to clean up in a portable fashion)

		- support for PM/DM (as we're discussing)

		- using the MD peephole to compress multiple instructions
		  into a single word.  THIS instruction packing might
		  be the most useful thing to incorporate into a
		  DSP target....  It certainly makes the SHARC
		  compiler look really smart sometimes....
	

	Still waiting to be tackled is fixing the problems with
	reorg so that it can handle multiple delay slots that are
	not identical (I posted a query about this a couple of weeks
	back....)

Regards,
-- Al

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

[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

[David Edelsohn]

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

David

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

[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

[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

[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 :(
|
|
|
|

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.

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

[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.  */

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 :(