From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78881 invoked by alias); 26 Apr 2016 18:22:06 -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 78839 invoked by uid 89); 26 Apr 2016 18:22:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=wide_int, sk:max_bit, sk:MAX_BIT, H*MI:googlemail X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Apr 2016 18:21:55 +0000 Received: by mail-wm0-f68.google.com with SMTP id e201so6563428wme.2 for ; Tue, 26 Apr 2016 11:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=Z17tOSwPTL2Nkkl/tMbVqIPJnJgkkPxtlPyOYRGaQpM=; b=Ten59sNe5z4mkVYawDR/qR9h0J1Wji+wcbxpCTYV2F2DI24t5mTIe/0JNHDn8CMhDL CVgAHvPsCTvXWTeVnEf3oGSuR9so7LxEITYiNwS8HLOTqM9N18qshyu+gND2INgRf6ie MYVAA40/aBuwObQPlabxAqxjlouzpX1MEK9cyZq4l4fzspgn6YkXEpN8ARVL/sBUoroo rm13hMeOSlWmnS1WRjzSJY5s1owTUr59WP1DUf6+U9EV+S2i7dR+S6+B07YVHltRRFCV agiKCwtJFh7eAE4yqOE1CJDOrkmNsaNxazlSs58+j4YPrrFqX2spKeREGl+ROtPYBL/0 ksVw== X-Gm-Message-State: AOPr4FXUWw+OT7KUlizZfFfTa+kfp5fWjzdI6e4s2qotI4IRBO7MHa0SagNzvSZnAfdCEg== X-Received: by 10.194.94.229 with SMTP id df5mr4740157wjb.176.1461694912240; Tue, 26 Apr 2016 11:21:52 -0700 (PDT) Received: from localhost ([95.145.138.157]) by smtp.googlemail.com with ESMTPSA id u4sm35455wjz.4.2016.04.26.11.21.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 11:21:51 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" ,gcc-patches@gcc.gnu.org, "H.J. Lu" , rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, "H.J. Lu" Subject: Re: [middle-end][PATCH] Update alignment_for_piecewise_move References: <20160426153346.GA18201@intel.com> Date: Tue, 26 Apr 2016 18:22:00 -0000 In-Reply-To: <20160426153346.GA18201@intel.com> (H. J. Lu's message of "Tue, 26 Apr 2016 08:33:46 -0700") Message-ID: <87wpnkdydd.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-04/txt/msg01527.txt.bz2 "H.J. Lu" writes: > I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset > optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128 > to keep the OI and XI modes from confusing the compiler into thinking > that these modes could actually be used for computation. But the OI > and XI modes can be used for data movement with vector instructions. But doesn't this then open the possibility that a memset or memcpy will be seen as a "normal" integer operation? Routines like simplify_immed_subreg could in principle create a constant integer for the stored value, which could then be treated by later passes as a wide_int, breaking the MAX_BITSIZE_MODE_ANY_INT assumption. Couldn't we move to allowing vector modes instead? That seems better than having to pander to the current situation in which every vector effectively needs an associated integer mode. Thanks, Richard