From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17281 invoked by alias); 30 Mar 2012 15:36:04 -0000 Received: (qmail 17118 invoked by uid 22791); 30 Mar 2012 15:36:02 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_XF X-Spam-Check-By: sourceware.org Received: from mail-ob0-f175.google.com (HELO mail-ob0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Mar 2012 15:35:40 +0000 Received: by obbwc20 with SMTP id wc20so1188839obb.20 for ; Fri, 30 Mar 2012 08:35:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-gm-message-state:content-type :content-transfer-encoding; bh=TWhdUiE/2UfM7v3Y8+ZplhZmtl0L9gIywofl4s/NgkM=; b=jNKSohDNPFFtz/RSwiyimfMkXeAW/a5uHjyDNf1lNijCG4bF0MaiET9JW1gEB7ZMxV L68MaGT7xCoiGVcDAqcmk6RSQKoRthmt0Izun+PimGO6UZCZTwY39BchsNr+9+W6jZYD iOo6mWYxk2sCVK8hckCBCLpff9NlBAEKEtkkk+xMCO59KTCv7CMe+YF55IE8YtbFP+1o n3LdWS9xPoVSYgP4p+cDKtCBpGbNo8ufthHQclL+yVyWYgG8cvr+rAjeOhCibaO0OFJU ENuTYAZlvDyaILDU63PKLPszU3XYH2o6nZ6+jB9kqUg+lRSUhxtM3NOKTxUADwy6rHnL pWQg== Received: by 10.182.114.70 with SMTP id je6mr3555325obb.30.1333121739419; Fri, 30 Mar 2012 08:35:39 -0700 (PDT) Received: from [192.168.1.10] (pool-98-113-157-191.nycmny.fios.verizon.net. [98.113.157.191]) by mx.google.com with ESMTPS id o9sm9499977obd.21.2012.03.30.08.35.38 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 08:35:38 -0700 (PDT) Message-ID: <4F75D2CB.4080807@naturalbridge.com> Date: Fri, 30 Mar 2012 15:36:00 -0000 From: Kenneth Zadeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Georg-Johann Lay CC: gcc-patches , Ian Lance Taylor , Richard Sandiford , Mike Stump , Kenneth Zadeck Subject: Re: [C Patch]: pr52543 References: <201203301439.q2UEdhSR011572@post.webmailer.de> In-Reply-To: <201203301439.q2UEdhSR011572@post.webmailer.de> X-Gm-Message-State: ALoCoQkxNr05lQFoBBFCvNYnqvIKs+dzWU2/Ul86F8ShTRfUjCwOdkkatZc18YiGMqmEE5iCKY1z Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-03/txt/msg01943.txt.bz2 On 03/30/2012 10:39 AM, Georg-Johann Lay wrote: >> This patch takes a different approach to fixing PR52543 than does the >> patch in >> >> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html >> >> This patch transforms the lower-subreg pass(es) from unconditionally >> splitting wide moves, zero extensions, and shifts, so that it now takes >> into account the target specific costs and only does the transformations >> if it is profitable. > As far as I understand the pass, it's not only about splitting these instructions > but also to the additional benefits of the split, i.e. AND 0xfffffffe will only need > one QI operation instead of 1 SI operation that costs 4 QI. > > And in fact, the positive benefit of subreg-lowering occurs with bit-wise operations > like AND, IOR, EOR etc. > > And one problem is that the pass is not sensitive to address spaces. > For example, HI splits for generic space are profitable, for non-generic > they are not. > > Thus, a patch should also address address-space sensivity. > No, this pass only splits operations that are wider than word mode into word mode sized chunks. On a machine where word mode is SI, it will split DI shifts and zero extends and any moves wider that SI mode into a series of SI operations. It does nothing for things in QI, or HI mode. The pass was written before there were machines with fast vector move operations. It might be that there are issues where the address space considerations may need to be taken into consideration. Someone who has a port with memory operation like this may want to consider making that enhancement. I think that once this patch is in place, that kind of change will be easier to incorporate. >> Unconditional splitting is a problem that not only occurs on the AVR but >> is also a problem on the ARM NEON and my private port. Furthermore, it >> is a problem that is likely to occur on most modern larger machines >> since these machines are more likely to have fast instructions for >> moving things that are larger than word mode. >> >> At compiler initialization time, each mode that is larger that a word >> mode is examined to determine if the cost of moving a value of that mode >> is less expensive that inserting the proper number of word sided >> moves. If it is cheaper to split it up, a bit is set to allow moves of >> that mode to be lowered. > As written above, the mode is *not* enough. For MEM there are is also > address space involved. > > Johann >