From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 615813858401 for ; Tue, 7 Feb 2023 14:39:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 615813858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wm1-x332.google.com with SMTP id m16-20020a05600c3b1000b003dc4050c94aso11629368wms.4 for ; Tue, 07 Feb 2023 06:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ALJbGJgaRmeuIUIA+r2LqJ0TMDCqyxxIQjJ1frtKMsY=; b=YphvMwXx1tgt1PvEOPnacmPBmsXd2pOL3fbQVkBdEaGgsD02nBa6LOH1MzRu7mk2B6 pDjUO793TNdm+OjI1TAjPErnmWHXpdHrt6HZ8TaIsiirxwZeKlEyhbjNty1MQqFd8Vrn H1Sg0TZqtNqkiPP31YszCw2sFzCXhb3Zy7RgD81gtRt3erVzhUvde9P0TwzAhl58ejk8 2CPNQyS+WyqszRFZVuZh1igM+anAnCyi3dM0D2sp1+jaGFaB4sGn53SVB+a0++O83wTJ aYUz8+/H29Cm6Z9zkHcIoCb5BxigLpT6/cI9dCsQAAkYfR7hKYUXgoQihBqu5btXboTJ bYag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ALJbGJgaRmeuIUIA+r2LqJ0TMDCqyxxIQjJ1frtKMsY=; b=sqeFkybeChwHuxDmf1eq8QFLoYT688FS8s1YiOEIAUIAOSaQ+YbHy22EPI1KAOPblx E8rDv/fKTFkXrbN81fEwhR/An3stqGSZuTfNGsLo39nTDpvCN64qpkB2ALMO0eFOsxXI 43jdPa6GwJRUT6FUo2mFiUnnZ1k+FzqKkHtZTQH1fggikQVgv8SkLiweWIs3mIGRpkvM aOa5FLL74RXeao8irRm9TJsV2GW5zRkpD7u5EqeOKZdizziEyiQhcaB/Acb75FbjXGrl bTH8jaDHZR4jznKTFI+it+ZlzRG1m1HBlSw6elUnPfzzbPet+fpreiA7cHQ275rN2JHw /A5A== X-Gm-Message-State: AO0yUKU4E4jxtjgWHC6Pbv2hJ3JFYT6ETx30MQgmyzHEXmOetmSDp2PW NUQY/YKp4qng4HAjvcZa5TWUxw== X-Google-Smtp-Source: AK7set+v8an6yPFC5guOPKir6pKJribFWkdXvBMOsPsOvRPz6lof5F++2i097V+0mjVmU2Zc6cpmZg== X-Received: by 2002:a05:600c:a291:b0:3e0:1a9:b1e0 with SMTP id hu17-20020a05600ca29100b003e001a9b1e0mr4110385wmb.25.1675780767340; Tue, 07 Feb 2023 06:39:27 -0800 (PST) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [2001:8b0:154:0:ea6a:64ff:fe24:f2fc]) by smtp.gmail.com with ESMTPSA id k10-20020a7bc30a000000b003dfee43863fsm12080149wmj.26.2023.02.07.06.39.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2023 06:39:26 -0800 (PST) Date: Tue, 7 Feb 2023 14:39:25 +0000 (GMT) From: "Maciej W. Rozycki" To: Fangrui Song cc: Jan Beulich , binutils@sourceware.org Subject: Re: objdump riscv: Stop disassembling addi rd, rs, 0 with a relocation as mv rd, rs? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Mon, 6 Feb 2023, Fangrui Song wrote: > In llvm-project, https://reviews.llvm.org/D143345 brings up the topic > whether we should keep addi rd, rs, 0 when it is associated with a > relocation. If it does, the relocation may resolve to a non-zero and > `mv rd, rs` may look confusing. I agree, I was quite amused when I came across it a while before, and I can imagine people may get confused. However it may be quite hard to implement given how the GNU disassembler has been structured; most easily probably by setting the `no_aliases' flag temporarily for any instruction seen with a relocation attached. This could have undesired consequences elsewhere though and would most likely make Jan unhappy who wants to see aliases in disassembly rather than machine instruction mnemonics with the immediate forms. So instead we may need another flag for the opcode table, such as INSN_NORELOC, which would exclude the given entry for instructions with any relocation attached; I think this would be the cleanest approach, though maybe a little bit more involving implementation-wise. Overall I can see it as an unfortunate side effect of choosing `ADDI rd, rs, 0' rather than `ADD rd, rs, x0' (why?) for the canonical MV macro encoding. Though of course it's the tools that have to adapt, not the other way round. FWIW, Maciej