From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 326E83857693 for ; Mon, 31 Oct 2022 16:50:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 326E83857693 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-lj1-x22f.google.com with SMTP id k19so17107553lji.2 for ; Mon, 31 Oct 2022 09:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U67WLpVxNsEw2oQNuf+O/pRQcU11cEonXTLtLc3NIOo=; b=QQNwAS8TpzYKGuCHW9FCKyI8t7mobd0NPaqiiTupIG1bcwQcgDd3TzJpETXDTdCOyr WnVi+YWli7pZYViQSPK9c4a46Pjvc2adfnP47881ou4NOOxj8VvS3LsXzFhQFxDjvOMg 63I2mGqE08PBQ8pdhBSFS8aWFtN1tTYzLrc3e0K9L5bJfmeIsEqp372sYnAQky8XQzpm UxWI6QVx+L7HefS0CZX4mCY7ylpHfi+qSo+A4N4TjmYME52AvlSaEOukWg/QLF1Vlu/3 GzFavUiBtROGvgtw/znCjMYd7DmyelkWGyDSNdxM/Oxnf+Tw+vHZ25jZOv8CeCBgFNch rCVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U67WLpVxNsEw2oQNuf+O/pRQcU11cEonXTLtLc3NIOo=; b=GUpVNyom39NBnJLO5Fn1L+2eLRrSA3TfTY8t7dEXnI1B7sG4KYIlQpkVMN5aHVVaTJ zUcMbIYdYxd1PnXumZD8zvSMop7dISd+dwhx9mi+xgkshHJlqv0OIYJFggw0r8+GLzRy bs96DDCAnISriRZu1M1dy5jb9mjZ6zkH8fI66c/lG2t5fPSPuqNGkxZvCycrOIpG/O+v X2qAqdCv103cgttBqo3L3qUcIUK1wW7eE5c33FStDAPFbCWZb8mmgmJtYN0V81Y5A5vg P/XercsOtzdowNasJByMRqwfpnzTyFyRXjP8PBMMJ6cPGn+Ve9tPybcuDoDkaNKf9FVs uv5w== X-Gm-Message-State: ACrzQf2WVcEdCbhVHkHVuuem6PJrVCddZlMM9hnvXW5m34TAF60SfBuS OT82CFtWOfCn8gwlnm4JCNt6K/whaD9w1cnhJhuRblLJJlE= X-Google-Smtp-Source: AMsMyM6RZ1qzv0er4NyCWmeERbv2BbNfsB2Dad0t3SkxYMpeRit3JGNhZvqNlvft3oqLEe7n1fW2CbxDxqBdYjh2/mo= X-Received: by 2002:a2e:870f:0:b0:277:2600:9d05 with SMTP id m15-20020a2e870f000000b0027726009d05mr5509695lji.144.1667235035527; Mon, 31 Oct 2022 09:50:35 -0700 (PDT) MIME-Version: 1.0 References: <20221014091248.4920-1-haochen.jiang@intel.com> <20221014091248.4920-7-haochen.jiang@intel.com> <1e6a7d9c-4b14-821e-cc46-453adbe6f183@suse.com> <2d296a73-760f-ea04-fcf8-4844552a31fe@suse.com> In-Reply-To: <2d296a73-760f-ea04-fcf8-4844552a31fe@suse.com> From: "H.J. Lu" Date: Mon, 31 Oct 2022 09:49:59 -0700 Message-ID: Subject: Re: [PATCH 06/10] Support Intel RAO-INT To: Jan Beulich Cc: "Jiang, Haochen" , "binutils@sourceware.org" , "Kong, Lingling" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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, Oct 31, 2022 at 2:42 AM Jan Beulich wrote: > > On 28.10.2022 18:08, H.J. Lu wrote: > > On Fri, Oct 28, 2022 at 1:40 AM Jan Beulich wrote: > >> > >> On 28.10.2022 10:31, Jiang, Haochen wrote: > >>>> -----Original Message----- > >>>> From: Jan Beulich > >>>> Sent: Friday, October 28, 2022 4:22 PM > >>>> > >>>> On 28.10.2022 10:10, Jiang, Haochen wrote: > >>>>> BTW, should the suffix instruction dependent? It might be more operand > >>>>> related from my opinion. If that is the truth, could we just judge > >>>>> whether we should add them when dealing with memory operands? > >>>> > >>>> I'm afraid I don't really understand what you're saying/asking here. > >>>> In any event - whether a suffix is required indeed depends on insn operands. > >>>> Yet even insns with (only) GPR operands _may_ use a suffix in AT&T mode, > >>>> irrespective of it being derivable from those GPR operands. We actually apply > >>>> consistency checks between registers used and the suffix (if present). > >>> > >>> What I am saying is we could put all the suffix module out of instructions. If we > >>> found that are using those variable GPR operands, then to determine whether > >>> we should allow suffixes instead of determining at instructions. > >> > >> Once again - even with GPR operands use of suffixes is permitted (and > >> actually kind of mandated by the only AT&T spec I'm aware of). You > >> may have seen the series that I have pending to re-work some of the > >> suffix recognition, but that's certainly not going in the direction > >> you're suggesting (if I understand what you're saying; perhaps if you > >> gave an example it might become more clear). > >> > > > > The old AT&T syntax rules, which are quite vague, don't apply to new > > instructions. > > Why would they not? These rules are intended to cover the full set of The rules are quite vague and the same mnemonic can mean very different instructions, depending on the operands. > insns. I'm afraid I need to keep repeating myself: Inconsistency here > leads to non-predictable overall behavior of the assembler (and of > the disassembler as well, in suffix-always mode, just that there it > won't lead to unexpected errors). We can't change the behavior of old instructions. For new instructions, the unnecessary suffixes should be avoided. > Jan > > > For new instructions, the suffix should be permitted and required only > > if it must > > be used to specify the operand size. > > > > > -- H.J.