From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 266C23857C71 for ; Tue, 22 Sep 2020 16:15:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 266C23857C71 Received: by mail-il1-x133.google.com with SMTP id a19so17850965ilq.10 for ; Tue, 22 Sep 2020 09:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sectWti3YHQOxbHG8swlWS3/M1P9ipjESXxfqj22P6A=; b=RyagCHeGYBp1HenvAmMRYxMRJ715nGp8IfGCf476U0Wc0oI/D+5NB8g5X0h/cZLEgS EU/9W3ppfPf5Cq9vi3Sm5AiQjo2IK/N5sBMEPBffMrh4BgKNPacbboinFTggEesJsMJo YxArS4zrbrl3AH0mpawnKgYFM8z97EA7StvD0QZMe5C8DvCeBV4zx0/fVvHIY9/rfPZT Yf9g6fMbDvxtcC4VhcI19jEX8DRaYoxC1cfcV4VxqgmmdWclRIcvNZJSJ0uB6r6cgfrJ dmJ5eWSRw1qyx8P3n6tNxiwZn6g1WbeDJwwKZVtLUeU/7HVZNFF6HLyh5AdBre126brJ FO1Q== X-Gm-Message-State: AOAM530NABBQT7r9uuUjuMsQgIKW9SvZB87WqKXabVyTD6NVX7xW9rBM 5Y75+E2E6zZAxjS3hMfqYBv2jb+m9cBHRDY0puY= X-Google-Smtp-Source: ABdhPJxpX760rTb/awMOb7/BaRMiwubHU2n9ZTAzdyX1l0kHof4ao56qVC0kUwXid9R4xRa/gGPkD0EUNgI2Rj2tLg4= X-Received: by 2002:a92:6a09:: with SMTP id f9mr5012879ilc.273.1600791331651; Tue, 22 Sep 2020 09:15:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Tue, 22 Sep 2020 09:14:55 -0700 Message-ID: Subject: Re: Enable support to Intel Key locker instructions. To: Jan Beulich Cc: "Cui, Lili" , "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.3 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 16:15:33 -0000 On Tue, Sep 22, 2020 at 9:08 AM Jan Beulich wrote: > > On 22.09.2020 10:53, Cui, Lili wrote: > >> On 21.09.2020 05:25, Cui, Lili wrote: > >>> --- a/opcodes/i386-dis.c > >>> +++ b/opcodes/i386-dis.c > >>> @@ -691,6 +691,7 @@ enum > >>> REG_0F18, > >>> REG_0F1C_P_0_MOD_0, > >>> REG_0F1E_P_1_MOD_3, > >>> + REG_0F38D8_PREFIX_1, > >>> REG_0F71, > >>> REG_0F72, > >>> REG_0F73, > >> > >> This addition wants to go further down. While not immediately visible here, ... > >> > >>> @@ -797,12 +798,18 @@ enum > >>> MOD_VEX_0F385E_X86_64_P_1_W_0, > >>> MOD_VEX_0F385E_X86_64_P_2_W_0, > >>> MOD_VEX_0F385E_X86_64_P_3_W_0, > >>> + MOD_0F38DC_PREFIX_1, > >>> + MOD_0F38DD_PREFIX_1, > >>> + MOD_0F38DE_PREFIX_1, > >>> + MOD_0F38DF_PREFIX_1, > >>> MOD_0F38F5, > >>> MOD_0F38F6_PREFIX_0, > >>> MOD_0F38F8_PREFIX_1, > >>> MOD_0F38F8_PREFIX_2, > >>> MOD_0F38F8_PREFIX_3, > >>> MOD_0F38F9, > >>> + MOD_0F38FA_PREFIX_1, > >>> + MOD_0F38FB_PREFIX_1, > >>> MOD_62_32BIT, > >>> MOD_C4_32BIT, > >>> MOD_C5_32BIT, > >> > >> ... in this table you'll notice that MOD_0F38* all go together, and _later_ > >> there's a MOD_VEX_0F38* group. I notice that recent additions (of yours?) also > >> already violate this sorting model - please may I ask for this to corrected as well? > >> The more outliers we have there, the more difficult will it be to maintain this > >> code. > > > > Thank you reviewing my patch. I put MOD_VEX_0F38* together. > > Imo this should be a separate change, not merged into here. Yes, please make a separate patch. > >>> @@ -8236,6 +8319,16 @@ static const struct dis386 mod_table[][2] = { > >>> /* MOD_0F38F9 */ > >>> { "movdiri", { Edq, Gdq }, PREFIX_OPCODE }, > >>> }, > >>> + { > >>> + /* MOD_0F38FA_PREFIX_1 */ > >>> + { Bad_Opcode }, > >>> + { "encodekey128", { Gd, Ed }, PREFIX_OPCODE }, }, { > >>> + /* MOD_0F38FB_PREFIX_1 */ > >>> + { Bad_Opcode }, > >>> + { "encodekey256", { Gd, Ed }, PREFIX_OPCODE }, }, > >> > >> The use of Gd and Ed will, afaict, lead to REX.W decoding as 64-bit register > >> operands, which according to doc and gas implementation looks wrong. > > > > I didn't find the code we use REX.W to determine the size of register with Gd and Ed. > > Could you help elaborate on it? It seems that Gd and Ed are correct. > > My mistake - I mixed up Gd/Ed with Gv/Ev, sorry. > > >>> +Unspecified|BaseIndex } aesdecwide256kl, 1, 0xf30f38d8, 0x3, 3, > >>> +CpuWIDEKL, > >>> +Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, > >> { > >>> +Unspecified|BaseIndex } > >> > >> ... these four need special treatment in output_insn()'s setting of > >> GNU_PROPERTY_X86_FEATURE_2_XMM, due to the lack of explicit RegXMM > >> operands. > >> > > Added it. > > If I was making a change like this, I'm pretty sure H.J. would ask me > to also add test cases for it. > Yes, please add a new testcase. See: commit a7e12755d57879884c523cae1cf009efc9da933c Author: H.J. Lu Date: Wed Feb 19 04:54:45 2020 -0800 x86: Mark cvtpi2ps and cvtpi2pd as MMX for an example. Thanks. -- H.J.