This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Implicit altivec vs. linux kernel build
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Geoff Keating <geoffk at geoffk dot org>, gcc at gcc dot gnu dot org, Paul Mackerras <paulus at samba dot org>, Alan Modra <amodra at bigpond dot net dot au>
- Date: Mon, 28 Feb 2005 09:57:22 +1100
- Subject: Re: Implicit altivec vs. linux kernel build
- References: <1109544228.15026.225.camel@gaston> <200502272253.j1RMrwD16992@makai.watson.ibm.com>
On Sun, 2005-02-27 at 17:53 -0500, David Edelsohn wrote:
> >>>>> Benjamin Herrenschmidt writes:
>
> Ben> There seem to be a problem with gcc 4.0 and implicit generation of
> Ben> altivec instructions when -mcpu=970.
>
> Ben> The problem is that the kernel cannot afford to use altivec instructions
> Ben> (nor FPU) except in controlled environment. Specifically, things like
> Ben> the RAID6 code has altivec (and SSE/2, which I think has a similar
> Ben> problem) implementation which runs in the proper environment.
>
> Ben> In order to build that, we have -mcpu=970. Unfortunately, with 4.0, that
> Ben> causes gcc to implicitely generate altivec code, which breaks it all.
>
> Geoff made the decision to enable Altivec implicitly for
> processors that support it and to use Altivec for block moves. We need to
> find out what he had in mind for situations like this.
>
> One work around is to use -mcpu=power4 instead of -mcpu=970, to
> avoid enabling Altivec when compiling kernel code.
Yes, but as I wrote, that prevents building the RAID6 code which
contains some selected altivec bits and cause gas to not get passed the
proper option so we can have instructions like "dssall" in the low level
assembly files.
The later can probably be worked around by adding the proper
Wa,-mcpu=any I suppose ... The RAID6 code is a bit more annoying since
currently, it's not a separate file.
Ben.