From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 7B4F63857026 for ; Mon, 29 Mar 2021 14:42:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7B4F63857026 Received: by mail-oi1-x234.google.com with SMTP id x2so13308487oiv.2 for ; Mon, 29 Mar 2021 07:42:18 -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=7UAfEXr3Ol2sM9Kx5scrpLWgMCNRIZ4ZrGr0v8yt/fM=; b=dPiAozh/cmipVScAnN3gFzRP2J6W7jdsdYlbIXOG+7SgdfNl8kPhU0dKiDWWl4O0KV UkZHfo5p5Yo1yFQ5h4Kh4UOxS4mP8OtICYjsKwvoWNrUlE0tqs4cdYWCa5LZAP38C8vF wgzGMkACW8bEcpH614qCRD3YWUYDs1Q0h3EFWHDA61Gk8fks2+XAdenHxcYWlmJmoErA iFMqlFrNLL83j6J2ZgwBbPXh4REqy8oaOIU6pnHumQJ7RVoDKxzJ7tj+gtsPZ3EMir5H 4zDC2Yx/Q47QPWFvgFCI/SJm/cmwIv8Q7CdHCR/kMzPLzoXnnb2kgFeAzt8YbIMkqHgC h+tw== X-Gm-Message-State: AOAM5333Y/DzGdT50UfLwzymhPbw4QWfRhINjKaFLWwITB6liRrNlCkA y3hrZOlI59dGwABhvsrZkaozWzJehP0zC9zCWKM= X-Google-Smtp-Source: ABdhPJwkX3bIVG7OV9O+9CQgjiiqstuBSocOTYPBz4ndi0ozs1OiLQYYWoI1S/7kzxsTLLoLKOCTeLwq6GFP/icC0Tc= X-Received: by 2002:a05:6808:94:: with SMTP id s20mr18675282oic.25.1617028937885; Mon, 29 Mar 2021 07:42:17 -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: <1ed07dfc-448e-1ec2-978a-6288da3fa576@suse.com> From: "H.J. Lu" Date: Mon, 29 Mar 2021 07:41:41 -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.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: Mon, 29 Mar 2021 14:42:19 -0000 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. -- H.J.