From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32124 invoked by alias); 4 Nov 2011 09:53:03 -0000 Received: (qmail 32110 invoked by uid 22791); 4 Nov 2011 09:53:02 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Nov 2011 09:52:45 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 3646D8CC2B; Fri, 4 Nov 2011 10:52:44 +0100 (CET) Date: Fri, 04 Nov 2011 10:11:00 -0000 From: Richard Guenther To: Jakub Jelinek Cc: Ira Rosen , Richard Henderson , gcc-patches@gcc.gnu.org Subject: Re: Patch ping In-Reply-To: <20111102201829.GT1052@tyan-ft48-01.lab.bos.redhat.com> Message-ID: References: <20111102201829.GT1052@tyan-ft48-01.lab.bos.redhat.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2011-11/txt/msg00514.txt.bz2 On Wed, 2 Nov 2011, Jakub Jelinek wrote: > Hi! > > - Gather vectorization patch + incremental patches > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html I'm not sure I like using new builtins for gather representation on the tree level too much, given that we are now moving towards using tree codes for suffle. Thus, how complicated would it be to have a gather tree code and optab and to handle the mixed size index issue in the expander? I realize this would be quite some reorg to the patchset ... so, why did you choose builtins over a more generic approach? > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html + if (TREE_CODE (base) == MEM_REF) { - off = TREE_OPERAND (base, 1); + if (!integer_zerop (TREE_OPERAND (base, 1))) + { + if (off == NULL_TREE) + { + double_int moff = mem_ref_offset (base); + off = double_int_to_tree (sizetype, moff); + } + else + off = size_binop (PLUS_EXPR, off, TREE_OPERAND (base, 1)); that's not safe, TREE_OPEAND (base, 1) is of pointer type, so you unconditionally need to do the conversion to sizetype of TREE_OPEAND (base, 1). The routine lacks comments - it's got quite big and fails to state any reason for its complexity. I'm also not sure why DR would include any loop invariant parts of the SCEV - doesn't it instantiate just for the loop in question? Thanks, Richard.