From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22992 invoked by alias); 1 Oct 2014 17:05:49 -0000 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 Received: (qmail 22983 invoked by uid 89); 1 Oct 2014 17:05:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f172.google.com Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com) (209.85.213.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 01 Oct 2014 17:05:47 +0000 Received: by mail-ig0-f172.google.com with SMTP id r2so118693igi.11 for ; Wed, 01 Oct 2014 10:05:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hsU1JUI75p8YBLFwvPFlF5S+ij4Ie7nLB+DMzn+RpMg=; b=ej+FhJFD3hIIJXkqJPrzhqbH3RGEYB3Og+uqwB2sDaEt10kKQIHpU2WvPOkBzfAIU6 abRjAzAokBg6b+r2xISdq2sYss+bO1VZjF6obj9hEoePLrRNaiBgaEBETh0vaPbj34oz VLgi+pGvZ3GhRjSYKY7EviyUiouVnUztHoCpMJvwxDFcvuTpqEh+lYPZMVhriBJhjOAR W1M+qX6WIETJpefV9/1eScRk4nvzzoH9t27xda8Ua5Cql8UAgfwhb8N4ttwys7/rs8aH eeHQUGqcYn5WtSEmEywvWyZ5AS6TRE8Z0Dum29lgvGE5MOCzgHwIoirzSnEDUFUgZasi brxg== X-Gm-Message-State: ALoCoQlThZFy1ZMoDFiaHppfO47jNqZyXW+6GTbFAnxaTjz6OCYWM1AcbPg31lKOobYRHl3yYF3S MIME-Version: 1.0 X-Received: by 10.50.108.38 with SMTP id hh6mr6447869igb.15.1412183145001; Wed, 01 Oct 2014 10:05:45 -0700 (PDT) Received: by 10.107.155.149 with HTTP; Wed, 1 Oct 2014 10:05:44 -0700 (PDT) In-Reply-To: <542BBE61.4060802@arm.com> References: <542BBE61.4060802@arm.com> Date: Wed, 01 Oct 2014 17:05:00 -0000 Message-ID: Subject: Re: [Patch AArch64] Fix extended register width From: Xinliang David Li To: Richard Earnshaw Cc: Eric Christopher , Marcus Shawcroft , Carrot Wei , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00085.txt.bz2 On Wed, Oct 1, 2014 at 1:42 AM, Richard Earnshaw wrote: > On 30/09/14 21:30, Eric Christopher wrote: >> On Tue, Sep 30, 2014 at 5:57 AM, Marcus Shawcroft >> wrote: >>> On 22 September 2014 19:41, Carrot Wei wrote: >>>> Hi >>>> >>>> The extended register width in add/adds/sub/subs/cmp instructions is >>>> not always the same as target register, it depends on both target >>>> register width and extension type. But in current implementation the >>>> extended register width is always the same as target register. We have >>>> noticed it can generate following wrong assembler code when compiled >>>> an internal application, >>>> >>>> add x2, x20, x0, sxtw 3 >>>> >>>> The correct assembler should be >>>> >>>> add x2, x20, w0, sxtw 3 >>> >> >> Hi Marcus, >> >>> Hi, >>> >>> The assembler deliberately accepts the first form as a programmer >>> convenience. Given the above example: >>> >> >> I've been doing some reading of the ARM-v8 ARM and the language the >> ARM uses here for this instruction matches the "shall" and not >> "should" language it uses in other locations: >> >> "Is the 32-bit name of the second general-purpose source register, >> encoded in the "Rm" field." >> >> This seems to say that a conforming assembler should error on a >> non-32bit named register here. As I said, same sort of verbiage used >> elsewhere for shall, in "should" cases the ARM is very careful to >> spell it out. >> >> Now if we want to change the ARM philosophy here I'm not opposed, but >> I think we'd want some more explicit documentation about how/where >> things should be more relaxed versus a bunch of "this is convenient to >> accept here" stuff. That kind of thing has a tendency to end up in >> some pretty fun context sensitive parsing madness. >> > > Agreed. We're already working on it... I assume you mean 'working on the documentation' ? David > > R. > >