From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 5018E3858D32 for ; Mon, 11 Dec 2023 08:02:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5018E3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5018E3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702281743; cv=none; b=uDAFlxYSRzZEBtP5+uQIJ5E2mykOAodJGu849NKpeEJ822xGJiDsOFeNRHXlBmU0Xi0QqOzEMAndZZuMXvivA3D4gFLfLgrEcM3FqP0i8ugIN50BYWcp2m6XsIkn1LXlgAz0dGI7cgtPc94UFoh25T3UIrkB2VHuByeymi/Q8NQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702281743; c=relaxed/simple; bh=qzSELyKOvjP2C6nvQsT4xey4EGDA3bkrjF9mQFePbmc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=skcLbFqtl/zri+OSvMPifEq/2Fl+3V/MoUxr9mxieZO2tGW50uhACX8hnctf4QnBd7EP7khyNijVpmo/z+hRBd9aEE7fhN80Uc4ka0c4aWsOUlOyv1klPhkvIeHxmGbLL/K0HL4vItIPaDVlsv8HyMX0/t24WHnFCbXnjduxmfc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-40c0fc1cf3dso44174815e9.0 for ; Mon, 11 Dec 2023 00:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1702281740; x=1702886540; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HLRNRhEB0aOqYpEf8RzSTtJTwvPfScvIvMmwR+leSD0=; b=GiasFVx5TeWYIQ3uTPv05TCW9GItACNw1wqhdvFMm8GaygiPOdx/sORVMN8Uba6tUW p0meL2hVhFKwGWowcJLV+eJdY2vJpBO3URtWk6GBUptWaxiz7D9Zo2CCbNo/kCl0Jsa3 3z027gPe72kmI+IY+2wXNUbM/saQ5rbYFUN/6OE1gRFlwjF4jtGZmIGeh8zeav2Ct5TM qnTG3AonFUgoIEtmCsI5jgwWHST3byeD83CPA5gaFBiRz1gc6GPi4V4+qq6fYW1cWjcM D7EU7Ws7W/y2elKIvT4z3UtNU3caj2TwZC+uE+06UiZn2aJrjV41BSF3ubVK18/XiqEt w7pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702281740; x=1702886540; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HLRNRhEB0aOqYpEf8RzSTtJTwvPfScvIvMmwR+leSD0=; b=joPFVqQsdrB2OiWbo5FEZQWf53GEG5wR2tzEM1u8Svdf6qd26fXQwmmSvh9ShB5Sez 2nwNOtFgkpUxOtW9nnl16eXCsyr80i5PxxjrlE0uB7zqCzFtHqrhWvXb/rliGTL7JiR7 zs2Mjhy3senVaBXTVNNT6qPhBJPsMQQDrTgwGDBY8Vb1OJoRCmUZnsnTw9pKiE3JL4fz k3oEN0bByelU4oNtbklLu4YTKqIUOq49xAFucexaDsDglo+9usO9f2Fpe+eUGMisIiQK x6C7eERLiXIALHGgr5rvm+sYpOh9ZFYzNu9xLJTNYefEhCqjqtUZhX3AU7jyTT8u8FNx CARg== X-Gm-Message-State: AOJu0YwITeg4pDrXbdXL651W6Sh7drn37DrCvfX5u64xL3NilghHMhN6 HngmpvHJmEWHhTnN6PcZJoWJ X-Google-Smtp-Source: AGHT+IGtOPmqh89OxwL0EAkfl8oSouzK+DGY2cOxa+WiA0ekq8f5Siy8gW2/315kaeyBxcm8kWPHTQ== X-Received: by 2002:a05:600c:246:b0:40c:c00:dfdb with SMTP id 6-20020a05600c024600b0040c0c00dfdbmr1941468wmj.11.1702281739990; Mon, 11 Dec 2023 00:02:19 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id fm21-20020a05600c0c1500b0040c03c3289bsm12081783wmb.37.2023.12.11.00.02.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Dec 2023 00:02:19 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2023 09:02:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH, V2 07/10] gas: synthesize CFI for hand-written asm Content-Language: en-US To: Indu Bhagat Cc: binutils@sourceware.org References: <20231030165137.2570939-1-indu.bhagat@oracle.com> <20231030165137.2570939-8-indu.bhagat@oracle.com> <47dec0fe-492e-43ec-8636-d33f6653d8f9@oracle.com> <37342fe7-2dc1-614a-f4c7-26e0b0318bbf@suse.com> <7450b823-a6f9-461b-85cb-5f7f99f8672e@oracle.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7450b823-a6f9-461b-85cb-5f7f99f8672e@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3026.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 10.12.2023 11:23, Indu Bhagat wrote: > On 11/6/23 03:03, Jan Beulich wrote: >> On 04.11.2023 08:29, Indu Bhagat wrote: >>> On 11/2/23 08:53, Jan Beulich wrote: >>>> On 30.10.2023 17:51, Indu Bhagat wrote: >>>>> +ginsnS * >>>>> +ginsn_new_mov (symbolS *sym, bool real_p, >>>>> + enum ginsn_src_type src_type, uint32_t src_reg, int32_t src_disp, >>>>> + enum ginsn_dst_type dst_type, uint32_t dst_reg, int32_t dst_disp) >>>>> +{ >>>>> + ginsnS *ginsn = ginsn_init (GINSN_TYPE_MOV, sym, real_p); >>>>> + /* src info. */ >>>>> + ginsn_set_src (&ginsn->src[0], src_type, src_reg, src_disp); >>>>> + /* dst info. */ >>>>> + ginsn_set_dst (&ginsn->dst, dst_type, dst_reg, dst_disp); >>>>> + >>>>> + return ginsn; >>>>> +} >>>> >>>> As indicated before, if both src and dst can be indirect here, ... >>>> >>>>> +ginsnS * >>>>> +ginsn_new_store (symbolS *sym, bool real_p, >>>>> + enum ginsn_src_type src_type, uint32_t src_reg, >>>>> + enum ginsn_dst_type dst_type, uint32_t dst_reg, int32_t dst_disp) >>>>> +{ >>>>> + ginsnS *ginsn = ginsn_init (GINSN_TYPE_STORE, sym, real_p); >>>>> + /* src info. */ >>>>> + ginsn_set_src (&ginsn->src[0], src_type, src_reg, 0); >>>>> + /* dst info. */ >>>>> + gas_assert (dst_type == GINSN_DST_INDIRECT); >>>>> + ginsn_set_dst (&ginsn->dst, dst_type, dst_reg, dst_disp); >>>>> + >>>>> + return ginsn; >>>>> +} >>>>> + >>>>> +ginsnS * >>>>> +ginsn_new_load (symbolS *sym, bool real_p, >>>>> + enum ginsn_src_type src_type, uint32_t src_reg, int32_t src_disp, >>>>> + enum ginsn_dst_type dst_type, uint32_t dst_reg) >>>>> +{ >>>>> + ginsnS *ginsn = ginsn_init (GINSN_TYPE_LOAD, sym, real_p); >>>>> + /* src info. */ >>>>> + gas_assert (src_type == GINSN_SRC_INDIRECT); >>>>> + ginsn_set_src (&ginsn->src[0], src_type, src_reg, src_disp); >>>>> + /* dst info. */ >>>>> + ginsn_set_dst (&ginsn->dst, dst_type, dst_reg, 0); >>>>> + >>>>> + return ginsn; >>>>> +} >>>> >>>> ... I can't see what these are needed for. >>>> >>> >>> For x86, they may not seem necessary. But for other architectures, or >>> say for future uses-cases, we may need them. I think it is more >>> meaningful (and readable) to see a LOAD/STORE/MOV ginsn for a machine >>> instruction of the same type. For other RISC-like ISAs, it is clearer >>> to have separate MOV/LOAD/STORE instructions. >>> >>> ginsn is meant to provide an infrastructure for other uses cases that >>> may crop up later. >> >> But then I consider it as odd that you munge loads/stores on x86 into >> ginsn_new_mov(), by using "indirect" operands. Imo it would be better >> to be consistent here, one way or the other. >> > > What I have not defined (deliberately) is any "temporary registers" in > ginsn. This means a CISC instruction cannot be split into multiple > gisnns with data dependencies. So to keep things simple, if machine > instruction is a MOV, we pick MOV ginsn (with indirect access if this > was a load/store). If the machine instruction is an ADD, we pick ADD > ginsn (with indirect access if applicable). > > If I understand you correct, you suggest that we pick load/store ops > like so: > mov disp(%reg), %reg --> load disp(%reg), %reg > mov %reg, disp(%reg) --> store %reg, disp(%reg) > > Then what about arith ops with indirect access ? In theory those are > load + arith + store. In other words, the above deliberation of picking > load/store for mov seems inconsistent then. If you don't decompose read-modify-write (memory destination) operations, then some kind of inconsistency is always going to be there. Jan