From patchwork Sat Mar 16 16:14:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Glisse X-Patchwork-Id: 228223 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 0F3092C00B2 for ; Sun, 17 Mar 2013 03:15:09 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1364055311; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=8t7xWaQ+/sz+fg8lyeXg0fhCJPg=; b=CxttEaj+9o1jPeg K0Hwgp94tEC7vX+596IJpzEtUDE1K3OgWs8zZDXskXXynVDss6j5Dp7TCntXfKFz sQcPblhGGd+wJ1JX7g7XKxMUNdgfdH0yorT4WDaz0kqL7CCsFELvZF8EOhrtc65m VCODR1ISdyguF2yWf3OXSDCnojJ8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=B/oV6lTb8kbys6HvJwbNx+hsK8r6UBgnwFLa8FL5OdKCCMJJFguClEGw16FJAn ng6CAzqO5oE+M5idRfwXpvK48IkaZd3vkIR4cF/kqocEC9QNpw1VkE4FleBq2S16 Tf27x8iV9HugN0F9KTzoQ7IiNe/hk+4F+i9xpy2er50SI=; Received: (qmail 3395 invoked by alias); 16 Mar 2013 16:14:53 -0000 Received: (qmail 3384 invoked by uid 22791); 16 Mar 2013 16:14:50 -0000 X-SWARE-Spam-Status: No, hits=-9.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 16 Mar 2013 16:14:45 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 16 Mar 2013 17:14:44 +0100 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.80) (envelope-from ) id 1UGtkp-0002Kg-FT; Sat, 16 Mar 2013 17:14:43 +0100 Date: Sat, 16 Mar 2013 17:14:42 +0100 (CET) From: Marc Glisse To: Eric Botcazou cc: gcc-patches@gcc.gnu.org Subject: Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector In-Reply-To: <1945553.ocCzHEE0OJ@polaris> Message-ID: References: <1945553.ocCzHEE0OJ@polaris> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Sat, 16 Mar 2013, Eric Botcazou wrote: >> My current understanding of simplify-rtx is that we should only do "safe" >> optimizations in it (make sure we only create expressions that every >> target will recognize), and if I want more advanced optimizations, I >> should do them elsewhere (not sure where). So I should probably at least >> restrict this one to the case where the result and XEXP (trueop0, 0) have >> the same mode. > > Yes, simplify-rtx should only canonicalize or simplify expressions. > Merging 2 VEC_SELECTs into a single one seems to fall into the second > category, but if no target can take advantage of it, that's probably a > bit questionable indeed. Thank you for the comment. I successfully regtested the attached trivial patch on x86_64-linux-gnu: 2013-03-16 Marc Glisse * simplify-rtx.c (simplify_binary_operation_1) : Restrict the transformation to equal modes. The original use case (and the testcase) are still handled. I don't think any target supports size(output) > size(input) for vec_select, so we don't lose anything. For size(output) < size(input), I can see one case in the x86 backend that could have used it: #include __v2sf f(__v4sf x){ return (__v2sf){x[0],x[1]}; } which ideally would exactly match sse_storelps (extractps is a vec_select:SF V4SF), but sadly it writes to memory instead of using a vec_concat so it doesn't benefit from the simplify-rtx code. sse_storehps is similar. (tree optimizations should have merged the 2 BIT_FIELD_REFs earlier, but that's a different issue) Even with the restriction we can still generate arbitrary permutations, which not all targets will recognize for every vector mode, but I guess there will be time to think about it if someone comes up with a testcase where this causes a problem. Is the patch ok for trunk (once 4.8.0 is out and the new server up)? Index: gcc/simplify-rtx.c =================================================================== --- gcc/simplify-rtx.c (revision 196701) +++ gcc/simplify-rtx.c (working copy) @@ -3619,21 +3619,22 @@ simplify_binary_operation_1 (enum rtx_co i - in_n_elts); } } return gen_rtx_CONST_VECTOR (mode, v); } /* Try to merge VEC_SELECTs from the same vector into a single one. */ if (GET_CODE (trueop0) == VEC_SELECT && GET_CODE (trueop1) == VEC_SELECT - && rtx_equal_p (XEXP (trueop0, 0), XEXP (trueop1, 0))) + && rtx_equal_p (XEXP (trueop0, 0), XEXP (trueop1, 0)) + && GET_MODE (XEXP (trueop0, 0)) == mode) { rtx par0 = XEXP (trueop0, 1); rtx par1 = XEXP (trueop1, 1); int len0 = XVECLEN (par0, 0); int len1 = XVECLEN (par1, 0); rtvec vec = rtvec_alloc (len0 + len1); for (int i = 0; i < len0; i++) RTVEC_ELT (vec, i) = XVECEXP (par0, 0, i); for (int i = 0; i < len1; i++) RTVEC_ELT (vec, len0 + i) = XVECEXP (par1, 0, i);