From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17735 invoked by alias); 6 Jul 2018 01:01:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17720 invoked by uid 89); 6 Jul 2018 01:01:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:5509588, H*i:sk:5509588, Hx-spam-relays-external:ESMTPA X-HELO: resqmta-po-04v.sys.comcast.net Received: from resqmta-po-04v.sys.comcast.net (HELO resqmta-po-04v.sys.comcast.net) (96.114.154.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 01:01:24 +0000 Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-04v.sys.comcast.net with ESMTP id bEMafxLopoqrobF7ifWb5q; Fri, 06 Jul 2018 01:01:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1530838882; bh=eqRcwhwU4Yl5MXnBi4z+sGXlDkEhR5CNtFj+ahvduq4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=WzOngGbU32zNrYJRCdw/2spZvja0PLN289niRu9vUfzuXBAgqKbWlnGuVFfV7+Yp5 5uIfJLqltC2xx4K/Q9vxkFcQGdwJVi8rOZYMTk6ns9R/FQB19doxNmynvpMhG5F8DU RsgwL/0dxLPHyISqAmUt6sZH+/HhQ9CL7p+O4Ycto9GtwA+Fv3YAqlie6df2n853sx Ml3LXKKMu3V5VJpI6VCSy/hRkWJFxOwKydOJINaagEbiFoV88ihz7Af/Oguk1eKvVl x2uWKJZwP4ZaAcfxEY8AHxuvQFzjs+9Gz28VSZD9SeZuyh5myphfklC25CFc+ykcWq eLpBanHY4AxpA== Received: from [192.168.10.125] ([73.60.223.101]) by resomta-po-19v.sys.comcast.net with ESMTPA id bF7hf2LdUoEJobF7ifxV0m; Fri, 06 Jul 2018 01:01:22 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Inefficient code From: Paul Koning In-Reply-To: <5509588.qb0lT0a25o@polaris> Date: Fri, 06 Jul 2018 01:01:00 -0000 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4684420.5pAmr275xc@polaris> <5509588.qb0lT0a25o@polaris> To: Eric Botcazou X-SW-Source: 2018-07/txt/msg00105.txt.bz2 > On Jul 5, 2018, at 6:47 PM, Eric Botcazou wrote: >=20 >> So back to the previous one: anything I can do about a 24 bit field gett= ing >> split into three movqi rather than a movqi plus a movhi? That happens >> during RTL expand, I believe. >=20 > Yes, this one doesn't look as hopeless as the store merging issue. A way= of=20 > tackling it would be to do a side-by-side debugging of a compiler built f= or a=20 > similar target for which only 2 stores are generated. I'll try xstormy16 since that's also 16 bit words, strict alignment. Then again, I fed the code to GCC for VAX and it also produces a sequence o= f 3 separate byte stores. No mixed endians there. paul