Trunk revision 216971 introduced LROTATE_EXPR as the canonical representation for a byte swap of a 2 bytes value, as per [1]. However, backend expects bswaphi patterns for such operation as these operation are more specific than a rotation. This led to a number of testcases starting to fail such as gcc.target/arm/builtin-bswap16-1.c and gcc.target/aarch64/builtin-bswap-2.c (these were skipped with my configuration). This patch adds a check in expmed to expand such LROTATE_EXPR into bswaphi pattern.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00616.html Note that this is unrelated to PR63761 (but I have diagnosed the root cause). ChangeLog entry is as follows: 2014-11-03 Thomas Preud'homme <thomas.preudho...@arm.com> * expmed.c (expand_shift_1): Expand 8 bit rotate of 16 bit value to bswaphi if available. diff --git a/gcc/expmed.c b/gcc/expmed.c index af14b99..7e86b59 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -2164,6 +2164,14 @@ expand_shift_1 (enum tree_code code, machine_mode mode, rtx shifted, code = left ? LROTATE_EXPR : RROTATE_EXPR; } + if (rotate + && CONST_INT_P (op1) + && INTVAL (op1) == BITS_PER_UNIT + && GET_MODE_SIZE (scalar_mode) == 2 + && optab_handler (bswap_optab, HImode) != CODE_FOR_nothing) + return expand_unop (HImode, bswap_optab, shifted, NULL_RTX, + unsignedp); + if (op1 == const0_rtx) return shifted; Is this ok for trunk? With the right configuration I could reproduce the test failure and with this patch both tests fail. Best regards, Thomas
