From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92391 invoked by alias); 5 Jul 2018 12:46:09 -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 92277 invoked by uid 89); 5 Jul 2018 12:45:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=Channel, Hx-languages-length:1099, transfer, Hx-spam-relays-external:ESMTPA X-HELO: resqmta-ch2-12v.sys.comcast.net Received: from resqmta-ch2-12v.sys.comcast.net (HELO resqmta-ch2-12v.sys.comcast.net) (69.252.207.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jul 2018 12:45:50 +0000 Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id b3B1fv9K2wfygb3dcfDHTn; Thu, 05 Jul 2018 12:45:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1530794732; bh=YGWNRnMMJpquOQ2O2E//BxTdFx3WPBomp53/B2nP9Zs=; h=Received:Received:From:Content-Type:Mime-Version:Subject: Message-Id:Date:To; b=mi2UV4stnaYJsejXmefxsiof9iZI1zLfoL5cjmYlUMqxzKsxx1U4sPj8rLu9wxhXv BTck89Ho8oFb7SjXolHSOsKCznSCIZ79UCmAaZ1DK0RrRwYOoSh8/08lLmwbQLLftC 6BcefNLx5gKe1y6YtUANe/SaO4YG/bE9uRmTT2RcSKQqYg/t6Z8kc09lmgOuPukSlF yNrqY8TLPlDLRQ9OoUosZOCSIfU8sr5I1AAzOZBYcJMCI18ltTLMzE66RadaiYeYRj SMMGP0wIJxQfTPVtZ7LyDzuVKJX1iy++xTx4QgbOw/skWFu9WGAkHD9T4EfIV75fkP UOtNL6mHyDvsQ== Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id b3dbfaEQgjw6Gb3dbfE06n; Thu, 05 Jul 2018 12:45:32 +0000 From: Paul Koning Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Inefficient code Message-Id: Date: Thu, 05 Jul 2018 12:46:00 -0000 To: GCC Development X-SW-Source: 2018-07/txt/msg00072.txt.bz2 I have a struct that looks like this: struct Xrb { uint16_t xrlen; /* Length of I/O buffer in bytes */ uint16_t xrbc; /* Byte count for transfer */ void * xrloc; /* Pointer to I/O buffer */ uint8_t xrci; /* Channel number times 2 for transfer */ uint32_t xrblk:24; /* Random access block number */ uint16_t xrtime; /* Wait time for terminal input */ uint16_t xrmod; /* Modifiers */ }; When I write to xrblk (that 24 bit field) on my 16 bit target, I get unexpe= ctly inefficient output: XRB->xrblk =3D 5; movb #5,10(r0) clrb 11(r0) clrb 7(r0) rather than the expected word write to the word-aligned lower half of that = field. Looking at the dumps, I see it coming into the RTL expand phase as a single= write, which expand then turns into the three insns corresponding to the a= bove. But (of course) there is a word (HImode) move also, which has the sa= me cost as the byte one. Is there something I have to do in my target definition to get this to come= out right? This is a strict_alignment target, but alignment is satisfied = in this example. Also, SLOW_BYTE_ACCESS is 1. paul