[OE-core] [PATCH] Revert "cross-canadian: Handle powerpc linux verses linux-gnuspe"

[alexandru.sardan at freescale.com]

Hi Richard,

I've tested your patch for both altivec and spe and it works fine.

Regards,
Alex

> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> Sent: Wednesday, January 29, 2014 1:39 PM
> To: Phil Blundell
> Cc: Sardan Alexandru Cezar-B41700; Udma Catalin-Dan-B32721; openembedded-
> core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] Revert "cross-canadian: Handle powerpc
> linux verses linux-gnuspe"
> 
> On Fri, 2014-01-24 at 20:56 +0000, Phil Blundell wrote:
> > On Thu, 2014-01-23 at 18:22 +0000, alexandru.sardan at freescale.com
> wrote:
> > > [Alex Sardan] No. The more generic target powerpc-none-linux will not
> > > generate SPE code and the powerpc-none-linux-gnuspe target that
> generates
> > > SPE will not be able to generate Altivec.
> >
> > Why not?  As far as I can tell from the gcc configury, the target
> string
> > only affects the defaults (i.e. powerpc-*-linux gets -mno-spe
> > -mno-altivec, powerpc-*-linuxaltivec gets -maltivec -mno-spec, and
> > powerpc-*-linuxspe gets -mno-altivec -mspe).  There doesn't seem to be
> > any real impact beyond this that would make the compiler binary
> > fundamentally incapable of generating either type of instruction if you
> > pass the appropriate options on the command line.
> 
> I had a closer look at this. The config.gcc case statements for powerpc
> only appear to let you include rs6000/linuxaltivec.h or
> rs6000/linuxspe.h, there doesn't appear to be a target you can pass in
> to get both.
> 
> Looking at the code in those files, I don't see any reason why you can't
> actually include support for both however. As such, I just hacked a
> build with:
> 
> tm_file="${tm_file} rs6000/linuxaltivec.h"
> tm_file="${tm_file} rs6000/linuxspe.h rs6000/e500.h"
> 
> and it certainly seems to build ok and compile things (this was just for
> qemuppc). I didn't try building altivec or spe specific things but
> looking at the code, I can't see any reason it wouldn't work at least in
> theory.
> 
> I'd suggest the easiest way to resolve this may be to patch gcc to
> include support for all the modes.
> 
> Cheers,
> 
> Richard
> 
>