From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBEFAC04EB9 for ; Mon, 3 Dec 2018 10:10:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BAC922087F for ; Mon, 3 Dec 2018 10:10:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAC922087F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726141AbeLCKKX convert rfc822-to-8bit (ORCPT ); Mon, 3 Dec 2018 05:10:23 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:23247 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726023AbeLCKKW (ORCPT ); Mon, 3 Dec 2018 05:10:22 -0500 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-32-M9eBV3i6N5mXzexFWVvs2A-1; Mon, 03 Dec 2018 10:09:56 +0000 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 3 Dec 2018 10:10:05 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Mon, 3 Dec 2018 10:10:05 +0000 From: David Laight To: 'Vineet Gupta' , 'Arnd Bergmann' , "jose.abreu@synopsys.com" CC: "open list:SYNOPSYS ARC ARCHITECTURE" , Linux Kernel Mailing List , "alexey.brodkin@synopsys.com" , Joao Pinto , "Vitor Soares" Subject: RE: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}() Thread-Topic: [PATCH v2] ARC: io.h: Implement reads{x}()/writes{x}() Thread-Index: AQHUh+/vHIi8Q+1XAUeZFbx1QKnaT6Vsz5DQ Date: Mon, 3 Dec 2018 10:10:05 +0000 Message-ID: References: <19fb2e394afcb073bbc109e432417fbbc03323f6.1543499759.git.joabreu@synopsys.com> <89122bd8-bca2-2ae1-0dd0-160abbebcace@synopsys.com> <57437493-31bb-eced-032c-1f54470b030e@synopsys.com> <3afe0e1bbf2d42d3bb178ec789553c28@AcuMS.aculab.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: M9eBV3i6N5mXzexFWVvs2A-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vineet Gupta ... > > It also seems to have used a different type of loop to the > > other example, probably less efficient. > > (Not that I'm an expert on ARC opcodes.) > > The difference is due to ISA and ensuing ARC gcc backends. ARCompact based cores > don't support unaligned access and the loop there was ZOL (Zero delay loop). In > ARCv2 based cores, the gcc backend has been tweaked to generate fewer ZOLs hence > you see the more canonical tst and branch style loop. Is this another case of the hardware implementing 'hardware' loop instructions that execute slower than ones made of simple instructions? The worst example has to be the x86 'loop' (dec cx and jump nz) instruction which is microcoded on intel cpus. That makes it very difficult to use the new addx instruction to get two dependency chains through a loop. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)