Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2654411imu; Thu, 29 Nov 2018 08:14:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/UMVa3VYBO9vqbGsKuQ3gHnACLSRSLrcI8HD9bSITkpN0sGXzDdZ/6//OaA+n93/oPwNlOc X-Received: by 2002:a63:e348:: with SMTP id o8mr1730245pgj.158.1543508065252; Thu, 29 Nov 2018 08:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543508065; cv=none; d=google.com; s=arc-20160816; b=UOKwhto32phJUPfA/TnLZWvQij4MBls33qiSpqe/9Zm5OOyNzDYOBhkSKx7JnD945n Pi8R8vgbWz/55faGbgjIz60zxxz1081o2R0BqI92qVaZx62JYiDW6e5JMOfGYQep+LzJ s/sDEv2EXjsFWSFnaNvoZD7KEsAVnPmO+JGWONI0Yky31tLdSVbKDYv40sJGaipKMqRP wDi1f+fxvIbo1eDffwhPuJh55QYZa+ixyh+KNlFoOBoqAc7lu2EO91kOHDZxYbypaq/O EhRt94EJ8tVdj+X2iFwyGfV8v7ywj4JKp1nDjzTrJYqkCzA9FTyhlHwwbGpUH8XbUSzk gU/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature; bh=z0YGdRoIW8lQhGJfxqCAFPByjHZx7kdeCOA1vuF8rB8=; b=OilGGvRhIKjU11YSFfIm7tsC8oOADShtwqzmyHUlEzb6jWze1Qf+v0lvqYYnNwgwa8 n0Y0LKssh96KTh8HbXdDb1eYkdI/+cPhXbNw0l4edxAcmt5M1XRdkXxqo/IoOpWu8N4W RsyKaDvvKTwe6zn3iVYOs72zJe8lGlWp71n8IF/mgOR1HQdW1i8Ts6RQeVxkW0z5axVC RlvCu66f5sznF4upf/pvWKZO7GHHo83rqI0J4Mic0iRdNY7IlBwz+A565qLk5qt2qnZr ox8p8dB2KftyzWbZlairFd/dNceOckrCzxumgURmveEUposQTv6arTrCYqS9PN7FeXmB 60TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b=End16h5w; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 8si2572813plc.88.2018.11.29.08.14.00; Thu, 29 Nov 2018 08:14:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b=End16h5w; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729351AbeK3DTC (ORCPT + 99 others); Thu, 29 Nov 2018 22:19:02 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:50752 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728504AbeK3DTB (ORCPT ); Thu, 29 Nov 2018 22:19:01 -0500 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id A506610C165A; Thu, 29 Nov 2018 08:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1543507989; bh=iI8VcSX2wwSpl+sNkdDq35GSueAOhPaM+gKpCn2bBKg=; h=Subject:To:References:CC:From:Date:In-Reply-To:From; b=End16h5wmjrbzF80Spi1zl5decbfFy+MsrVwCJ8TcpLqkybiOw7tTDPUvcnIXGCBz JXVO/uUMgGF4E7p3TRCdtKr0enCLV/T5OjEVoejTFjG6+c7ei2vz2C9H79Hfd8kmEO ry6SwXh1DibOgMq8ZY3qLPuMLLfK9+xESxl5YYEVcrr5o570NQya8M+f0nYKEwFIII Da3So6pu2j1J0shPMpQEWffzMQfT5qgqoNifX9xkbl0JvAZVcwRKouo28wBV0ATXdD xfccMPN89cGR/M1vvWD+/A7/5ug52BC8qULGlYYIbPxVWslZhvb5YrPsa2X857vyte XXspU01B6/mtg== Received: from US01WEHTC3.internal.synopsys.com (us01wehtc3.internal.synopsys.com [10.15.84.232]) by mailhost.synopsys.com (Postfix) with ESMTP id 6295931A3; Thu, 29 Nov 2018 08:13:09 -0800 (PST) Received: from DE02WEHTCA.internal.synopsys.com (10.225.19.92) by US01WEHTC3.internal.synopsys.com (10.15.84.232) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 08:13:09 -0800 Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.94) by DE02WEHTCA.internal.synopsys.com (10.225.19.92) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 17:13:07 +0100 Received: from [10.0.2.15] (10.107.19.26) by DE02WEHTCB.internal.synopsys.com (10.225.19.80) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 17:13:06 +0100 Subject: Re: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}() To: David Laight , "linux-snps-arc@lists.infradead.org" , "linux-kernel@vger.kernel.org" References: <19fb2e394afcb073bbc109e432417fbbc03323f6.1543499759.git.joabreu@synopsys.com> <89122bd8-bca2-2ae1-0dd0-160abbebcace@synopsys.com> CC: Vineet Gupta , Alexey Brodkin , Joao Pinto , "Vitor Soares" From: Jose Abreu Message-ID: Date: Thu, 29 Nov 2018 16:13:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <89122bd8-bca2-2ae1-0dd0-160abbebcace@synopsys.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.107.19.26] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29-11-2018 14:42, Jose Abreu wrote: > On 29-11-2018 14:38, David Laight wrote: >> From: Jose Abreu >>> Sent: 29 November 2018 14:29 >>> >>> Some ARC CPU's do not support unaligned loads/stores. Currently, generic >>> implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC. >>> This can lead to misfunction of some drivers as generic functions do a >>> plain dereference of a pointer that can be unaligned. >>> >>> Let's use {get/put}_unaligned() helper instead of plain dereference of >>> pointer in order to fix this. >> ... >>> +#define __raw_readsx(t,f) \ >>> +static inline void __raw_reads##f(const volatile void __iomem *addr, \ >>> + void *buffer, unsigned int count) \ >>> +{ \ >>> + if (count) { \ >>> + const unsigned long bptr = (unsigned long)buffer; \ >>> + u##t *buf = buffer; \ >>> +\ >>> + do { \ >>> + u##t x = __raw_read##f(addr); \ >>> +\ >>> + /* Some ARC CPU's don't support unaligned accesses */ \ >>> + if (bptr % ((t) / 8)) { \ >>> + put_unaligned(x, buf++); \ >>> + } else { \ >>> + *buf++ = x; \ >>> + } \ >>> + } while (--count); \ >>> + } \ >>> +} >> Does the compiler move the alignment test outside the loop? >> You really want two copies of the loop body. > Hmm, I would expect so because the if condition takes two const > args ... I will try check that. And it did optimize :) Sample C Source: --->8-- static noinline void test_readsl(char *buf, int len) { readsl(0xdeadbeef, buf, len); } --->8--- And the disassembly: --->8--- 00000e88 : e88: breq.dr1,0,eac <0xeac> /* if (count) */ e8c: and r2,r0,3 e90: mov_s lp_count,r1 /* r1 = count */ e92: brne r2,0,eb0 <0xeb0> /* if (bptr % ((t) / 8)) */ e96: sub r0,r0,4 e9a: nop_s e9c: lp eac <0xeac> /* first loop */ ea0: ld r2,[0xdeadbeef] ea8: st.a r2,[r0,4] eac: j_s [blink] eae: nop_s eb0: lp ed6 <0xed6> /* second loop */ eb4: ld r2,[0xdeadbeef] ebc: lsr r5,r2,8 ec0: lsr r4,r2,16 ec4: lsr r3,r2,24 ec8: stb_s r2,[r0,0] eca: stb r5,[r0,1] ece: stb r4,[r0,2] ed2: stb_s r3,[r0,3] ed4: add_s r0,r0,4 ed6: j_s [blink] --->8--- See how the if condition added in this version is checked in and then it takes two different loops. Thanks and Best Regards, Jose Miguel Abreu > > Thanks and Best Regards, > Jose Miguel Abreu > >> David >> >> - >> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK >> Registration No: 1397386 (Wales) >>