This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Alias code - how does the SHARC do it..
- To: Alan Lehotsky <lehotsky at tiac dot net>
- Subject: Re: Alias code - how does the SHARC do it..
- From: "Michael P. Hayes" <michaelh at ongaonga dot chch dot cri dot nz>
- Date: Fri, 3 Jul 1998 03:06:51 GMT
- Cc: "Michael P. Hayes" <michaelh at ongaonga dot chch dot cri dot nz>, Joern Rennecke <amylaar at cygnus dot co dot uk>, law at cygnus dot com, Franz dot Sirl-kernel at lauterbach dot com, mark at markmitchell dot com, egcs at cygnus dot com
- References: <199806301840.TAA04463@phal.cygnus.co.uk><199806301022.KAA20139@ongaonga.chch.cri.nz><199807010023.AAA23563@ongaonga.chch.cri.nz><v04011702b1c09b19d96b@[192.168.1.254]>
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.