From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 302B43857026 for ; Mon, 29 Mar 2021 14:51:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 302B43857026 Received: by mail-oi1-x22d.google.com with SMTP id x2so13336250oiv.2 for ; Mon, 29 Mar 2021 07:51:53 -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=TBpoDMw1hYEMmT11ywM6Yl825G1bG/RFYWa1KkEYpTo=; b=CqUmDnIrjeP5CNVzw2wPL5fQBBfjT8vvn88JcqL5S+cmv9JacKvZhN/CoMx9TMA+Pc K569beEXmEztl1dVG3eCsEMt1+RmJ8d/ew6TtMdFSioRYa0js1qUzPCpiu/6C3K/4bM2 rzlbisyzkbmMjqDQbfJ0Rm/vJkxfqhuz8ipyqGCiFGrskKbISZ9HwMQYnsI4NHNZh0yA +gdHBv4anJ/hALeNL2UWFEJ+DZuKzrXin55MSuWWVmZX8j2pp3BzPAOBt/BdSTe7Xmx3 Fr4AaavB5Ddq+dukwnYKLoymScNKF7dYJku+zvd1xwAbAEwl4puWfT0NeMsiDWAqov/2 n5+g== X-Gm-Message-State: AOAM5306LPYiXKYULvbrgb93fKhQsXiQULQ55SmbCn9PoRcdIHJhC/bf dwtys8pDyrZ44+hDCaZdV9mf+Ijd2Q8r9yoO64py5Etonp0= X-Google-Smtp-Source: ABdhPJx5O1XNSHx2PufbcziVOsxDzg6R++I+6mdZdeVgIGqyXzfPIwOAiGmYL1skVIX5XFr8/3FVy+1suK7/RfEMo4E= X-Received: by 2002:aca:530e:: with SMTP id h14mr18998560oib.79.1617029512662; Mon, 29 Mar 2021 07:51:52 -0700 (PDT) MIME-Version: 1.0 References: <287ad145-1fe3-2477-327a-30e8d45a4be7@suse.com> <379a1b1a-f48f-3070-ee76-1b460450d518@suse.com> <1ed07dfc-448e-1ec2-978a-6288da3fa576@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 29 Mar 2021 07:51:16 -0700 Message-ID: Subject: Re: [PATCH 2/6] x86: shrink some struct insn_template fields To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3029.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.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: Mon, 29 Mar 2021 14:51:54 -0000 On Mon, Mar 29, 2021 at 7:49 AM Jan Beulich wrote: > > On 29.03.2021 16:41, H.J. Lu wrote: > > On Mon, Mar 29, 2021 at 7:03 AM Jan Beulich wrote: > >> > >> On 29.03.2021 15:00, H.J. Lu wrote: > >>> On Fri, Mar 26, 2021 at 3:50 AM Jan Beulich wrote: > >>>> > >>>> Now that all base opcodes are only at most 2 bytes in size, shrink its > >>>> template field to just as much. By also shrinking extension_opcode and > >>>> operands to just what they really need, we can free up an entire 32-bit > >>>> slot (plus 4 left bits past the bitfields themselves). > >>>> > >>>> At present this alters sizeof(struct insn_template) only for 32-bit > >>>> builds. In 64-bit builds it instead leaves a padding hole that will > >>>> allow to buffer future growth of other fields (opcode_modifier, > >>>> cpu_flags, operand_types[]). > >>>> > >>>> opcodes/ > >>>> 2021-03-XX Jan Beulich > >>>> > >>>> * i386-opc.h (struct insn_template): Shrink base_opcode to 16 > >>>> bits. Shrink extension_opcode to 9 bits. Make it signed. Change > >>>> value of None. Shrink operands to 3 bits. > >>>> --- > >>>> Code-generation wise it may be better to move the signed > >>>> extension_opcode field last within the containing 32-bit slot. > >>> > >>> extension_opcode should be next to opcode in template. > >> > >> In the source table, in the binary representation, or both? (I certainly > >> agree they should be next to each other in the source table.) > > > > Only in the source code, not in the binary representation. > > Yet the remark was about the (positive) code gen effects changing the > binary representation was likely to have. I then understand you wouldn't > object to moving this field. > Correct. -- H.J.