From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 2A286385769D for ; Mon, 31 Oct 2022 16:25:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2A286385769D 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-lf1-x12c.google.com with SMTP id d6so20034770lfs.10 for ; Mon, 31 Oct 2022 09:25:28 -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=Ys1C+jQXnA4l0eClqscYiNcbtL4mbO4x2n+aQrdXgjA=; b=jgLZb+QQwvcvKS2RAEX9ICDDZvVLU42XqvlEDmJty4jVgJVUxvRcpsWjfVhdMLJe34 ElucOxtkbDW4PAPtYkUBqkueOm7gZt3vkBu478TkhZpgenscV19NmXJJ+7ZukfuEps3v OD9+OzQNzrG4DE0LKD41DbHmQxvvawlKvNue5paAQ//id85Ze4a8zQbn3Gr919+iXKsV eCN0LymcbA7XLgqHI3IJ5IUPhSfrZY8AH+Ud8YYFVcJds8dqLocuW83nkWzqCNYvoxZv h7EtnIaMWkePjXJJzKBwz1Zv66eVIv/ahapVXwYvVeRsL2zOWIP2tLJLN9gvkoOcJwdV Rg/A== 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=Ys1C+jQXnA4l0eClqscYiNcbtL4mbO4x2n+aQrdXgjA=; b=s6k7qK0LWlydW3HFDcn1RnddEJqPRnznbFrxbRv8Q7QUGbavlgVbi9cbzA0nhQztMf yCGfWvuheoz4hVDP+4zufEcgCmGMnSeCmseom41b2o3Thn6350BUfIK4Ifgkgbz0FQtr olVvSzabpZ8ibwX/oksQCp80FeSu03Oc17VvXHESnmb4XozYT0LUeN6Q6ydmB6u7YW8u C65nmtccok9EUt6VBgNjmd3FL/EKpjBJnpjz3uWJBpT8CES5He+ZluQE87nAMEITxla8 GZ9bmuvjouhG8x/a+7dXi5zPPldT4P7nFLl0hkSB9QeYkfZD3HFaJLw7/nkxNUkrxrwf 6u9Q== X-Gm-Message-State: ACrzQf0iFpG+RV+YkXkCq/nOu8AuhPJtjEEiWox2k8/MZ7gYbo0FIokJ ub4Hho9GgYdAsKJxuSqi3AzvP4Om8Ei7nXtR8rU= X-Google-Smtp-Source: AMsMyM59sihXFvDP+kpGwBP0S1LyJYK33HVv+U/Y7ajYnaGwGZ4/XZOcWZ91331G0GiGFBQ9JBEtE782H7HCTxBOB6Q= X-Received: by 2002:a05:6512:4002:b0:4a2:6243:8384 with SMTP id br2-20020a056512400200b004a262438384mr5513086lfb.29.1667233526768; Mon, 31 Oct 2022 09:25:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Mon, 31 Oct 2022 09:24:50 -0700 Message-ID: Subject: Re: [PATCH] x86: minor improvements to optimize_imm() (part III) To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3016.8 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 3:11 AM Jan Beulich wrote: > > On 28.10.2022 18:03, H.J. Lu wrote: > > On Fri, Oct 28, 2022 at 5:35 AM Jan Beulich wrote: > >> > >> Earlier tidying still missed an opportunity: There's no need for the > >> "anyimm" static variable. Instead of using it in the loop to mask > >> "allowed" (which is necessary to satisfy operand_type_or()'s assertions) > >> simply use "mask", requiring it to be calculated first. That way the > >> post-loop masking by "mask" ahead of the operand_type_all_zero() can be > >> dropped. > >> > >> --- a/gas/config/tc-i386.c > >> +++ b/gas/config/tc-i386.c > >> @@ -1906,7 +1906,6 @@ operand_type_xor (i386_operand_type x, i > >> > >> static const i386_operand_type disp16_32 = OPERAND_TYPE_DISP16_32; > >> static const i386_operand_type anydisp = OPERAND_TYPE_ANYDISP; > >> -static const i386_operand_type anyimm = OPERAND_TYPE_ANYIMM; > >> static const i386_operand_type regxmm = OPERAND_TYPE_REGXMM; > >> static const i386_operand_type imm8 = OPERAND_TYPE_IMM8; > >> static const i386_operand_type imm8s = OPERAND_TYPE_IMM8S; > >> @@ -5812,13 +5811,6 @@ optimize_imm (void) > >> const insn_template *t = current_templates->start; > >> > >> operand_type_set (&mask, 0); > >> - allowed = t->operand_types[op]; > >> - > >> - while (++t < current_templates->end) > >> - { > >> - allowed = operand_type_and (allowed, anyimm); > >> - allowed = operand_type_or (allowed, t->operand_types[op]); > >> - } > >> switch (guess_suffix) > >> { > >> case QWORD_MNEM_SUFFIX: > >> @@ -5837,7 +5829,14 @@ optimize_imm (void) > >> default: > >> break; > >> } > >> - allowed = operand_type_and (mask, allowed); > >> + > >> + allowed = operand_type_and (t->operand_types[op], mask); > >> + while (++t < current_templates->end) > >> + { > >> + allowed = operand_type_or (allowed, t->operand_types[op]); > >> + allowed = operand_type_and (allowed, mask); > > > > mask isn't changed in the loop. Can the AND operation be moved after > > the loop? > > Initially I thought it could, yes, but it cannot: As said in the > description the AND-ing "is necessary to satisfy operand_type_or()'s > assertions". > > Jan OK. Thanks. -- H.J.