[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fftw3: Patch for powerpc build failure

On Fri, 2004-01-02 at 09:11, Steven G. Johnson wrote:
> Steven G. Johnson wrote:
> > Can you tell us whether -mabi=altivec is really required for programs 
> > calling FFTW?  I never did figure out exactly what this flag does on 
> > Linux.  (It is not needed for 16-byte stack alignment, apparently, since 
> > I think that is guaranteed by the SVR4 ABI.)
> I checked with my co-author on this, and there is an additional problem:
> Currently, FFTW detects Altivec by reading an altivec register that says 
> whether it is enabled...on other machines, e.g. a G3, this causes a 
> SIGILL and we use setjmp/longjmp to recover from the trap.  However, 
> last he checked, gcc -mabi=altivec caused setjmp/longjmp to try to save 
> altivec registers, failing on the G3.  There are several possible 
> workarounds, but since the ABI seemed incompatible we gave it up as a 
> lost cause.

Well... that's a problem, though I expect glibc to deal with that
more gracefully... Possibly only an upcoming version.

> So, with the current version of FFTW, the runtime Altivec detection will 
> not work under Linux on non-Altivec machines (last we checked), and 
> should therefore be disabled in the standard Debian ppc package.

You can detect differently by using the ELF AUX tables
passed by the kernel to any executable. The AT_HWCAP entry contains
"feature" bits, one of them indicating the support of Altivec, see
the kernel include/asm/cputable.h for the bit definitions.

> If you can assure us that the ABIs are compatible on Debian, and that 
> -mabi=altivec won't cause FFTW to fail on e.g. a G3 for other reasons, 
> we can revisit this issue and try to come up with a way to detect 
> Altivec support properly at runtime.  (There is also still the question 
> of whether altivec-FFTW-calling programs need -mabi=altivec, and whether 
> this will break them on non-altivec architectures.)

Reply to: