Re: PATCH: named address space support (2/2: SPU backend)

[<Trevor_Smigiel at playstation dot sony dot com>]

Ben,

In t-spu-elf, I'm confused by the new targets.  Are they supposed to be
multilib?  If so, shouldn't they use $(T) instead of having duplicate
rules? And include $(MULTILIB_CFLAGS).  For example, change

  cachemgr.o: $(srcdir)/config/spu/cachemgr.c
          $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -c $< -o $@

  %/cachemgr.o: $(srcdir)/config/spu/cachemgr.c
          $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -c $< -o $@

to

  $(T)cachemgr.o: $(srcdir)/config/spu/cachemgr.c
          $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) $(MULTILIB_CFLAGS) -c $< -o $@


In spu_cache.h, can you include the "unlimited exception" versions of
the GNU license exceptions?  I've seen it in other headers.  We don't
like the "compiled with GCC" part of the current exception used.

Otherwise it looks ok, assuming there are no major changes after the
first part of the patch is accepted.

Trevor

* Ben Elliston <bje@au1.ibm.com> [2008-08-20 22:15]:
> This patch follows on from the target-independent patch I posted
> yesterday at:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01353.html
> 
> The patch below uses the infrastructure introduced by yesterday's patch
> to implement one named address space for the spu-elf target: __ea.  The
> patch includes an implementation of a software-managed cache to improve
> performance of programs accessing variables in the PPU address space.
> 
> Tested for no effects on powerpc-linux and x86_64-linux.  There are no
> regressions on spu-elf, although the gcc.target/spu/cache.c test is
> currently failing due to missing newlib support that will be committed
> in the next week or so.  If there is a strong desire to do so, we can
> xfail that test in the meantime.
> 
> The documentation changes were tested with "make info dvi" and visual
> inspection of the resulting .dvi files.
> 
> Okay for mainline?
> 
> Thanks, Ben
>