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

[Alan Lehotsky <lehotsky at tiac dot net>]

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