On Wed, Jan 08, 2014 at 12:10:13AM +0000, Andrew Pinski wrote: > On Tue, Jan 7, 2014 at 4:05 PM, Marcus Shawcroft > <marcus.shawcr...@arm.com> wrote: > > > > Andrew, We know that there are numerous issues with aarch64 BE advsimd > > support in GCC. The aarch64_be support is very much a work in progress. > > Tejas sorted out a number of fundamentals with a series of patches in > > November, notably in PCS conformance. There is more to come. However, > > aarch64_be-* support in gcc 4.9 is not going to match the level of quality > > for the aarch64-* port. > > > Yes but should not introduce an ICE while GCC is in stage3. This was > working before due not having a vec_perm before. I am going to > request this to be reverted soon if it is not fixed (the GCC rules are > clear here).
Hi Andrew, I am confused, are you also proposing to revert this patch on 4.8 branch? The code has been sitting with that assert in place on trunk for well over a year (note that December 2012 was during 4.8's stage 3, not 4.9) there is no regression here. But, that doesn't absolve me of the fact that this is broken in a stupid way for big-endian AArch64. The band-aid, which I can prepare, would be to turn off vec_perm for BYTES_BIG_ENDIAN targets on the 4.9 and 4.8 branches. This is the most sensible thing to do in the short term. Naturally, you will lose vectorization of permute operations, but at least you won't get the ICE or wrong code generation. This is what the ARM back-end (from which I ported the vec_perm code) does. In the longer term you would want to audit the lane-numbering discrepancies between GCC and our architectural lane-numbers. We are some way towards that after Tejas' PCS conformance fix, but as Marcus has said, there is more to come. I should imagine that in this case you will need to provide a run-time transformation between the permute mask and an appropriate mask for tbl. To reiterate, this does not need reverted, we'll get a fix out disabling vec_perm for BYTES_BIG_ENDIAN on 4.8 branch and 4.9. Thanks, James
