On Fri, Oct 24, 2014 at 12:27 PM, Konstantinos Margaritis <[email protected]> wrote: > On Fri, 24 Oct 2014 12:13:16 -0300 > Felipe Sateler <[email protected]> wrote: >> I had a few questions regarding the patch for enabling altivec on >> ppc32, I'll repeat them here: >> >> I'm very ignorant on altivec (or simd in general), but I try to >> understand the patch anyway. This patch seems to consist mostly of >> s/vector/__vector/. Why is that? I presume the upstream code works on >> apple platforms, is that an important difference? The second part is >> adding -mabi=altivec and -maltivec, which is unfortunately not >> possible, because that would contaminate the rest of the binaries with >> altivec code. AFAIK, debian still supports non-altivec machines. >> (supernova requires altivec, but for other machines we have scsynth). > > Ok, the problem is that recently gcc enables also __APPLE_ALTIVEC__ as > well, which defines the vector keyword. However, that proves just how > bad of a choice this keyword was, as it collides with both STL and > Boost -if you leave it out you'll eventually have a failed compile at: > > /usr/include/boost/mpl/vector.hpp:36:73: fatal error: > boost/mpl/__attribute__((altivec(vector__)))/__attribute__((altivec > (vector__)))20.hpp: No such file or directory > # include BOOST_PP_STRINGIZE(boost/mpl/vector/AUX778076_VECTOR_HEADER) > > (see how vector is replaced with _attribute__((altivec(vector__)))
Ah, OK, makes sense. Indeed, that is a bad word choice. But I find it weird that cpp would try to replace vector inside an include statement. Perhaps this is one reason it works in apple platforms but not for us. > > That has been a problem ever since, and the only solution is to #undef > vector and usually typedef new types, that map to eg. __vector float, > etc. > >> Perhaps a more correct patch would alter the logic in >> server/supernova/CMakeLists.txt to allow passing the >> required flags just to supernova > > That alone won't do for the reasons above. Hmm, it seems I was unclear. With this comment I was referring to adding -maltivec and -mabi=altivec wholesale to supercollider (in d/rules), not the vector attribute replacing code. > >> I'm somewhat wary of adding this patch this close to the freeze... > > Sure, that could come after the freeze, I guess the most important one > would be to just disable altivec for now for ppc64le only, both > powerpc/ppc64 have altivec by default so that won't break the existing > packages. OK, will try to upload this later today (no promises though). FWIW, I wouldn't mind an NMU for this change, although I'd try changing the explicit setting with DEB_*FLAGS_APPEND, so that we still have the optimization and hardening flags (I believe cdbs recently fixed this usage). > > And you're right, that powerpc is supposed to support non-altivec > systems as well. I was thinking that maybe it would be a good idea to > build a separate -altivec package if there is interest -and not too > much trouble :) That would be an option, but it would require some work and I don't have any ppc hardware ;). Possibly it could make sense to optimize the server and unit generators only. Hmm, if a solution can be found using ld paths (like libav), maybe this can also be used to enable sse in the i386 version... I'd have to investigate further. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
