public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Alias code
       [not found] <199806291730.KAA16121@cygnus.com>
@ 1998-06-29 20:41 ` Jeffrey A Law
  1998-06-30  4:50   ` Michael P. Hayes
  0 siblings, 1 reply; 7+ messages in thread
From: Jeffrey A Law @ 1998-06-29 20:41 UTC (permalink / raw)
  To: Franz Sirl; +Cc: mark, egcs

  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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code
  1998-06-29 20:41 ` Alias code Jeffrey A Law
@ 1998-06-30  4:50   ` Michael P. Hayes
  1998-06-30 14:46     ` Joern Rennecke
  0 siblings, 1 reply; 7+ messages in thread
From: Michael P. Hayes @ 1998-06-30  4:50 UTC (permalink / raw)
  To: law; +Cc: Franz Sirl, mark, egcs

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.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code
  1998-06-30  4:50   ` Michael P. Hayes
@ 1998-06-30 14:46     ` Joern Rennecke
  1998-07-01  0:54       ` Michael P. Hayes
  0 siblings, 1 reply; 7+ messages in thread
From: Joern Rennecke @ 1998-06-30 14:46 UTC (permalink / raw)
  To: Michael P. Hayes; +Cc: law, Franz.Sirl-kernel, mark, 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?

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code
  1998-06-30 14:46     ` Joern Rennecke
@ 1998-07-01  0:54       ` Michael P. Hayes
  1998-07-02  1:39         ` Alias code - how does the SHARC do it Alan Lehotsky
  0 siblings, 1 reply; 7+ messages in thread
From: Michael P. Hayes @ 1998-07-01  0:54 UTC (permalink / raw)
  To: Joern Rennecke; +Cc: Michael P. Hayes, law, Franz.Sirl-kernel, mark, egcs

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code - how does the SHARC do it..
  1998-07-01  0:54       ` Michael P. Hayes
@ 1998-07-02  1:39         ` Alan Lehotsky
  1998-07-03  1:51           ` Michael P. Hayes
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Lehotsky @ 1998-07-02  1:39 UTC (permalink / raw)
  To: Michael P. Hayes
  Cc: Joern Rennecke, Michael P. Hayes, law, Franz.Sirl-kernel, mark, egcs

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code - how does the SHARC do it..
  1998-07-02  1:39         ` Alias code - how does the SHARC do it Alan Lehotsky
@ 1998-07-03  1:51           ` Michael P. Hayes
  1998-07-03 12:21             ` Alan Lehotsky
  0 siblings, 1 reply; 7+ messages in thread
From: Michael P. Hayes @ 1998-07-03  1:51 UTC (permalink / raw)
  To: Alan Lehotsky
  Cc: Michael P. Hayes, Joern Rennecke, law, Franz.Sirl-kernel, mark, egcs

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Alias code - how does the SHARC do it..
  1998-07-03  1:51           ` Michael P. Hayes
@ 1998-07-03 12:21             ` Alan Lehotsky
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Lehotsky @ 1998-07-03 12:21 UTC (permalink / raw)
  To: michaelh; +Cc: amylaar, law, Franz.Sirl-kernel, mark, egcs

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~1998-07-03 12:21 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <199806291730.KAA16121@cygnus.com>
1998-06-29 20:41 ` Alias code Jeffrey A Law
1998-06-30  4:50   ` Michael P. Hayes
1998-06-30 14:46     ` Joern Rennecke
1998-07-01  0:54       ` Michael P. Hayes
1998-07-02  1:39         ` Alias code - how does the SHARC do it Alan Lehotsky
1998-07-03  1:51           ` Michael P. Hayes
1998-07-03 12:21             ` Alan Lehotsky

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).