On Thu, Aug 16, 2012 at 07:34:29PM +0100, Måns Rullgård wrote: > Diego Biurrun <[email protected]> writes: > > On Thu, Aug 16, 2012 at 11:29:53AM +0100, Måns Rullgård wrote: > >> Diego Biurrun <[email protected]> writes: > >> > On Thu, Aug 16, 2012 at 12:10:52AM +0100, Mans Rullgard wrote: > >> >> There used to be one test for Altivec intrinsics support and a > >> >> separate test to determine which of two possible syntaxes to use > >> >> for vector literals. Since 2008, we only support the more common > >> >> of these so the split test no longer makes sense. > >> >> > >> >> This combines the tests into one and also changes the hard error on > >> >> failure to a warning. The test can reasonably fail if no --cpu flag > >> >> is provided (or is provided with an unknown CPU) and the compiler > >> >> default target does not support Altivec. Aborting in this case is > >> >> probably over-reacting. > >> >> > >> >> --- a/configure > >> >> +++ b/configure > >> >> @@ -2873,17 +2873,14 @@ elif enabled ppc; then > >> >> check_cc <<EOF || disable altivec > >> >> $inc_altivec_h > >> >> int main(void) { > >> >> - vector signed int v1, v2, v3; > >> >> - v1 = vec_add(v2,v3); > >> >> + vector signed int v1 = (vector signed int) { 0 }; > >> >> + vector signed int v2 = (vector signed int) { 1 }; > >> >> + v1 = vec_add(v1, v2); > >> >> return 0; > >> >> } > >> >> EOF > >> >> > >> >> - # check if our compiler supports braces for vector declarations > >> >> - check_cc <<EOF || die "You need a compiler that supports {} in > >> >> AltiVec vector declarations." > >> >> -$inc_altivec_h > >> >> -int main (void) { (vector int) {1}; return 0; } > >> >> -EOF > >> >> + enabled altivec || warn "Altivec disabled, possibly missing > >> >> --cpu flag" > >> >> fi > >> > > >> > Merging the two tests is OK, but you should also merge the two comments > >> > then. IIRC this caused a lot of grief back in the day when the compiler > >> > did not support the syntax used in libavcodec. It would fail after a > >> > long and expensive compile. Erroring out early in configure was done > >> > on purpose. I believe we should keep that behavior, since the compile > >> > error later on would be equally fatal. > >> > >> I don't understand what you are trying to say. It still checks for the > >> same things, but disables altivec with a warning rather than aborting if > >> the check fails. There will be no error later. > > > > Indeed, brainfart from my side. Please merge the comments nonetheless. > > There is no need. The braces mentioned in the second comment _are_ the > Motorola syntax. > > > I feel obliged to raise one more point though: On x86 we error out if > > (yasm) optimizations will not be included in the build, why not here? > > Very simple. Yasm is a tool separate from the compiler that, if > missing, would result in an extremely slow build. The Altivec > intrinsics are supported by every compiler capable of building Libav at > all (and a few more). The only sane reason the test can fail is someone > building for a target lacking Altivec without passing a --cpu option we > recognise as such. Insisting on explicitly disabling Altivec in such > situations would be inconsistent with how we handle optional features on > other targets.
OK, push anytime. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
