From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21392 invoked by alias); 29 Dec 2014 17:09:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 21375 invoked by uid 89); 29 Dec 2014 17:09:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 29 Dec 2014 17:09:24 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 60360AC45; Mon, 29 Dec 2014 17:09:19 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <000401d02370$6167b440$24371cc0$@arm.com> References: <000401d02370$6167b440$24371cc0$@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] Don't check for optab for 16bit bswap From: Richard Biener Date: Mon, 29 Dec 2014 17:53:00 -0000 To: Thomas Preud'homme ,gcc-patches@gcc.gnu.org Message-ID: X-SW-Source: 2014-12/txt/msg01932.txt.bz2 On December 29, 2014 3:04:36 PM CET, Thomas Preud'homme wrote: >Since 16bit byteswap can be done via an 8 bit rotation (and it is the >canonical form), >the check for an optab only serves to prevent the bswap optimization >for >targets that don't have a 16bit byteswap (but do have a rotation >instruction). See >PR63259 (comments 6 and onwards) for more details. OK, but what about targets without a rotation optab? Is the fallback expansion reasonable in all cases? Richard. >ChangeLog entry is as follows: > >2014-12-24 Thomas Preud'homme thomas.preudhomme@arm.com > >PR tree-optimization/63259 >* tree-ssa-math-opts.c (pass_optimize_bswap::execute): Stop checking >if optab exists for 16bit byteswap. > > >diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c >index 1ed2838..c175e88 100644 >--- a/gcc/tree-ssa-math-opts.c >+++ b/gcc/tree-ssa-math-opts.c >@@ -2350,15 +2350,13 @@ unsigned int > pass_optimize_bswap::execute (function *fun) > { > basic_block bb; >- bool bswap16_p, bswap32_p, bswap64_p; >+ bool bswap32_p, bswap64_p; > bool changed = false; >- tree bswap16_type = NULL_TREE, bswap32_type = NULL_TREE, >bswap64_type = NULL_TREE; >+ tree bswap32_type = NULL_TREE, bswap64_type = NULL_TREE; > > if (BITS_PER_UNIT != 8) > return 0; > >- bswap16_p = (builtin_decl_explicit_p (BUILT_IN_BSWAP16) >- && optab_handler (bswap_optab, HImode) != CODE_FOR_nothing); > bswap32_p = (builtin_decl_explicit_p (BUILT_IN_BSWAP32) > && optab_handler (bswap_optab, SImode) != CODE_FOR_nothing); > bswap64_p = (builtin_decl_explicit_p (BUILT_IN_BSWAP64) >@@ -2367,12 +2365,6 @@ pass_optimize_bswap::execute (function *fun) > > /* Determine the argument type of the builtins. The code later on > assumes that the return and argument type are the same. */ >- if (bswap16_p) >- { >- tree fndecl = builtin_decl_explicit (BUILT_IN_BSWAP16); >- bswap16_type = TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))); >- } >- > if (bswap32_p) > { > tree fndecl = builtin_decl_explicit (BUILT_IN_BSWAP32); >@@ -2443,11 +2435,6 @@ pass_optimize_bswap::execute (function *fun) > if (code == LROTATE_EXPR || code == RROTATE_EXPR) > continue; > load_type = uint16_type_node; >- if (bswap16_p) >- { >- fndecl = builtin_decl_explicit (BUILT_IN_BSWAP16); >- bswap_type = bswap16_type; >- } > break; > case 32: > load_type = uint32_type_node; >@@ -2469,7 +2456,7 @@ pass_optimize_bswap::execute (function *fun) > continue; > } > >- if (bswap && !fndecl) >+ if (bswap && !fndecl && n.range != 16) > continue; > > if (bswap_replace (cur_stmt, src_stmt, fndecl, bswap_type, >load_type, > >Bootstrapped on x86_64-linux-gnu and aarch64-none-linux-gnu without any >testsuite regression > >Is this ok for trunk? > >Best regards, > >Thomas