From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geoff Keating To: Stan Shebs Cc: gcc-patches@gcc.gnu.org Subject: Re: altivec patches Date: Tue, 13 Nov 2001 04:32:00 -0000 Message-ID: References: <1004993660.30179.533.camel@litecycle.cc.andrews.edu> <200111052158.NAA22392@geoffk.org> <3BE71290.86CEE765@apple.com> X-SW-Source: 2001-11.fuckfuckfuck/msg00270.html Message-ID: <20011113043200.GlwBJY2WiCxRFFfOLYZe1Rumpoj68UX4whHbgFYZqi0@z> Stan Shebs writes: > Geoff Keating wrote: > > > > The DWARF_FRAME_REGISTERS change seems to have gone away, which is not > > quite right: it has to happen _only when the ABI is 'altivec'_. > > > > This will be a bit tricky because DWARF_FRAME_REGISTERS is also used > > in libgcc, so you have to #define something when the Altivec ABI is > > chosen, and then key off that if IN_LIBGCC2. > > Thus we slide down the slippery slope... Solving this completely > eventually entails having a method to detect whether the CPU > supports AltiVec instructions - in the case of a C++ throw > in code using AltiVec registers, you need to detect dynamically > (Apple's GCC uses a bit set by the kernel) whether you're on a > G4 or a not-G4. So you may have to generate a frame descriptor > that mentions registers you won't actually manipulate on a not-G4. Unfortunately, such a method doesn't exist in many environments. (In particular, it's not in the powerpc UISA, which is all you can really rely on in GCC.) > Our GCC just sets DWARF_FRAME_REGISTERS to FIRST_PSEUDO_REGISTERS > unconditionally, seems to work well enough for non-AltiVec code. Can't do that; breaks backwards binary compatibility. That's why DWARF_FRAME_REGISTERS was invented, so people could add registers without breaking binary compatibility. -- - Geoffrey Keating