From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 3336F3860764 for ; Sat, 22 Jul 2023 15:14:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3336F3860764 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1b852785a65so19858665ad.0 for ; Sat, 22 Jul 2023 08:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690038895; x=1690643695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/NOak4boNjEku8T0/6De5ZSEN4PA9hcaxHvNgEvVg70=; b=quCtuIIFjHqfwFLAxz1PfTOQrGPo6E3bMNuAeJinf4SNihCZ2CcUq4sQqR3Jyoqgb3 Rw6lk+z+ZziADFsroE5Mu+fVBmHyjaNwPkjkyh33YQShweNBwDr/OUYzcHq+6ZWdO1Ks r9Aa0P7pmNrqSeYvs4cwJicZ8sGfbN0Po54rWK9xc2tcTbkigNxE3Ta/NBpUpKxO8497 161FSeT2UpD3Xbpp257nJv5Gwn1+KSqboBszCd3DjX3f59SeyI0iob+FWdFZBQz6TspF Ud2bDYkxuALn2aUL/sUknQvBJ3PP+r2lq7b7O+tVxIam2xCh2diPr90UwWgDUDVg331B au4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690038895; x=1690643695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/NOak4boNjEku8T0/6De5ZSEN4PA9hcaxHvNgEvVg70=; b=PgpDW1thLlBtIskN5ZcYgjaGPDNaN5P1rIqcwz5jSn2Aj4PW2kuc3H83yB+lFi6Q2s LqkuPPJJz266ASzm1LR10BO07NAXAm/CeFqYxIDZj/tOSWMZSJ+NooBvRZNN6/oP+QjX vuVstKovQRiEY/bn1DbUu1u3zfDyNxrEJLX2aMyBs8LvWR+U7Ak2O/HpeB7ImzCsFdgl kNWVmI7JEZQSidVhbnZPllwWNnDRXOPBijzEDYvl9xrrKxpvLoE4mf56zx+qmL29Vz2q SmAg0Q08NqM5kY+MRjKO634vvUvQguwKWX0imPtGdUxenClvqRhUufqszk8KsFWh0dEc 0Jww== X-Gm-Message-State: ABy/qLbQHdTScqDWOKGleS67g9vrpq5BTeULpqfkjmJr5DoDT1wvPcj4 ekRhIPaCbKVRvL/9ZqbTZIn7CmSP798b+A== X-Google-Smtp-Source: APBJJlGV1th3lKknNpZ13jcpNfZnnrBZaUmf9mdN7PARm37q1KxWHyLnLdriFgq6oCVJvXR90H0Syw== X-Received: by 2002:a17:902:ea0a:b0:1b0:3d03:4179 with SMTP id s10-20020a170902ea0a00b001b03d034179mr6689378plg.6.1690038894856; Sat, 22 Jul 2023 08:14:54 -0700 (PDT) Received: from [172.31.1.103] ([172.56.168.196]) by smtp.gmail.com with ESMTPSA id kx14-20020a170902f94e00b001a6d4ea7301sm5463404plb.251.2023.07.22.08.14.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jul 2023 08:14:54 -0700 (PDT) Message-ID: <9b8011b2-2f15-96ea-9891-cc385cfcc9c9@gmail.com> Date: Sat, 22 Jul 2023 09:14:52 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 1/3] RISC-V: re-arrange opcode table for consistent alias handling Content-Language: en-US To: Song Fangrui , Jan Beulich , Nelson Chu Cc: Stefan O'Rear , Binutils , Jessica Clarke , "kito.cheng@sifive.com" References: <7cb92a0b-d1ef-e3db-4773-0b6cd5183272@suse.com> <40281e59-659c-044f-0c86-1db77fd17b5c@suse.com> <09666d48-99f0-ae25-ef84-f542da3628ce@suse.com> <18227b09-0d51-3e24-b782-5cf74e41e494@suse.com> <8c44aaa6-7dac-4b1b-9558-33d15ed9b9f8@app.fastmail.com> <09d96f5d-a547-6c3b-f0f2-b40484fa5a9f@suse.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 7/21/23 16:16, Song Fangrui wrote: > On Sun, Jul 16, 2023 at 11:50 PM Jan Beulich wrote: >> >> On 15.07.2023 00:08, Stefan O'Rear wrote: >>> On Fri, Jul 14, 2023, at 5:25 PM, Fangrui Song wrote: >>>> On Wed, Jul 12, 2023 at 1:15 AM Jan Beulich wrote: >>>>> On 11.07.2023 23:02, Fangrui Song wrote: >>>>>> I apologize as I haven't read all prior discussions. For many >>>>>> instructions, the "i" form is written in the ISA manual and prevalent. >>>>> >>>>> Why "prevalent"? The "i"-less forms are mentioned there as well, aren't >>>>> they? Then why not use them ... >>>> >>>> I think aliases like "add rd,rs,imm" (without "i") should be treated >>>> as deprecated aliases that we keep just for compatibility. >> >> That's a matter of taste, I'm inclined to say. But see below. >> >>>> We should not endorse the use cases by making objdump -d "prefer" this form. >>>> >>>> When I brought up the topic in the #riscv channel on libera.chat, I >>>> got a lot of complaints about having these "deprecated" aliases from >>>> folks, including courmisch, jrtc27, muurkha, sorear. >>>> As I happen to know two folks' email addresses, I have CCed them in this thread. >>>> >>>>>> I wonder whether we can give these add/and/xor/etc without "i" lower >>>>>> priority so that objdump -d will not show them, even without using -M >>>>>> no-aliases. >>>>> >>>>> ... unless use of aliases was suppressed? In other arches' assembly >>>>> that I know (to some degree) and which knows the concept of aliases, >>>>> aliases are typically the preferred way of disassembling, for >>>>> typically producing easier to grok output. >>>> >>>> AIUI aliases for other architectures are indeeded preferred (use my >>>> understanding of llvm-objdump -d output). >>>> This RISC-V case is not, though. >>> >>> The aliases that are documented in [1] are preferred for use in disassembly. >>> The other aliases, which gas supports for compatibility with old versions of >>> itself but which were never part of any spec, are not preferred. >> >> This would be a fair policy, as long as there's a not overly troublesome >> way of getting further entries on that list (whenever obvious instances >> turn up). My main goal, after all, is consistency. What exact policy >> underlies this is secondary to me. >> >> Jan > > Jan and Nelson, If this is agreed that we should use "addi" instead of > the gas alias "add" in situations like addi x0, x0, 1, can either of > you make a change to restore the old behavior? Thanks! Given the ISA docs use "addi", we should follow that. While GAS does provide aliases which allow things like "add" with an immediate operand, those are non-standard and should not be preferred. In an ideal world the output of objdump should be compatible with what GAS accepts as well as what the LLVM toolchain accepts -- while we may not be there, there's no good reason to introduce additional inconsistencies across the tools. So as Stefan noted, there are a set of aliases defined by the RISC-V assembly reference. Those are the only ones that should be preferred. > https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md jeff