On 12/20/2010 8:35 AM, Ulrich Weigand wrote: > Matthias noticed the following ICE when attempting to build the SPU > compiler from the Linaro GCC 4.5 sources:
With our Linaro hats on, is this something about which we should be concerned -- other than in so far as we want to get the patch accepted upstream? The purpose of the Linaro compiler is presumably for ARM; I think it's reasonable to put in changes that benefit ARM even if they are negative elsewhere -- with the caveat that since we want everything to go upstream we do of course need to resolve these issues in the upstream context. But, resolving them upstream and resolving them in the Linaro sourcebase are two different things. To me, it seems that using the Linaro tools (or kernel or whatever) on many other architectures is likely to be problematic, no matter how well-intentioned everyone is, at any given point in time, given that the whole focus of the organization is on ARM. LinCell/B.E.o, anyone? :-) Seriously, what's the commitment we're making as an organization with respect to (a) correctness, and (b) performance on non-ARM architectures? If this isn't already documented, it should be an explicit Linaro policy. > Now, I guess there's two ways forward: either the outcome of the ongoing > discussions on gcc-patches is that it is in fact not a good idea to > generate such sets, and the EE pass is subsequently rewritten to avoid > them; or else, if those instructions are considered valid, I'll have to > extend the SPU move expander to handle them. Thoughts? I haven't participated in the upstream discussion -- I'm way behind on that list :-( :-( -- but I think such sets should be considered valid. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
