From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24333 invoked from network); 2 Jul 2021 16:05:10 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jul 2021 16:05:10 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id C18959C8E4; Sat, 3 Jul 2021 02:05:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C39099C86C; Sat, 3 Jul 2021 02:04:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="YnYsEu+n"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 37E019C864; Sat, 3 Jul 2021 02:04:24 +1000 (AEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by minnie.tuhs.org (Postfix) with ESMTPS id 6470B9C861 for ; Sat, 3 Jul 2021 02:04:23 +1000 (AEST) Received: by mail-vs1-f50.google.com with SMTP id h5so4320631vsg.12 for ; Fri, 02 Jul 2021 09:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=f3zSeqb3KowqLsGrXwsfHntkDbVyOByAUpTTizr14Jc=; b=YnYsEu+nopjEA0nqhsShrHFvuOdyhiIWIaXgQkE2ZqdaJbUwxYUm4His3KyjcI/ZMa pUBLqgMHn3Ruj4zEvHGwJjiUFL/ihvq7Xtfw+Gm16TckZ27nDJCskiAgmmfooUbABN9Z K+hfx5/Z+09tY9EcGzclHLYYtwUG53eBxGHaXBtH5hNE2KGiYQREGLDmQXMhZRFnti9L XRa7HNgayAAOs3P+gqv+nSDqQgh/+gE8y0Ut+m0d+4O5bEddokuKjJKP3f9am37rfncW nDQdY7yGstVNYFSXpUE5Iab8Z2N3WKa95Vr8eXuE1Mbj5fH0yP35ExGp10ILsQO7pNk/ 462g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=f3zSeqb3KowqLsGrXwsfHntkDbVyOByAUpTTizr14Jc=; b=rP1yd4nVFMMc50pDgSclFM5EFF76DRwSf1vy0igiC0SbBTr7kdfdVelNOy0iAzdlWI /G79aHf7O29jxlekper70CSjAYsBh6KG1IFb7gRRXwfzoRBkroxYpRcqFptGS0zwTQdL BXbwFUoZjMUiquD0Iz+++i+SaDYBmhFls2UqWGdkmD2wqMlMjSk//NCT3OsY/kUmOmD3 kuhcc+I37cewXgzr2y0fHkOj+XGWxtr5UYhL0INoyc499DVNQ00fcLLzA8cCVL8sWFSG YiZpIv7QxsqkIWQeek2c2MR5qutESkQwiKFTMW4iKiKDUPmbSTGXpUtGPYu7dxmRytqk HtMA== X-Gm-Message-State: AOAM531kwPhiZZcIS4tu91kSDAq9jXYZfaqHMQdygRczfwYjir66TnUt 7+RQvFu8MODZVIJzWs+kkSG6oxWAGHnuHh5I+P4= X-Google-Smtp-Source: ABdhPJzi2A97W5VTvNzMG5wdaN6r4x/otTATiNkKUuKmbPB3dqDWd3MlKBPqTlmls37INeTD4ZsmgQrwTJ7k1hll3mo= X-Received: by 2002:a05:6102:e92:: with SMTP id l18mr135233vst.19.1625241862592; Fri, 02 Jul 2021 09:04:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:7517:0:0:0:0:0 with HTTP; Fri, 2 Jul 2021 09:04:21 -0700 (PDT) From: Paul Winalski Date: Fri, 2 Jul 2021 12:04:21 -0400 Message-ID: To: scj@yaccman.com Content-Type: text/plain; charset="UTF-8" Subject: [TUHS] pointer disambiguation (was Re: Disassemers) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 7/1/21, scj@yaccman.com wrote: > When PCC came along and started running on 32-bit machines, I started > thinking about algorithms for optimization. A problem that I had no > good solution for could be illustrated by a simple piece of code: > > x = *p; > > y = *q; > > q gets changed > > *q = z; > > The question is, do I need to reload x now because q might have been > changed to point to the same place as p? Yes, this is a very well-known problem in scalar optimization in compiler engineering. It's called pointer disambiguation and is part of the more general problem of data flow analysis. As you observed, getting it wrong can lead to very subtle and hard-to-debug correctness problems. In the worst case, one has to throw out all current data flow analysis of global and currently active local variables and start over. In your example, the statement "*q = z" may end up forcing the compiler to toss out all data flow information on x and z (and maybe p and q as well). If q could possibly point to x and x is in a register, the assignment forces x to be reloaded before its next use. Ambiguous pointers prohibit a lot of important optimizations. This problem is the source of a lot of bugs in compilers that do aggressive optimizations. Fortunately a bit of knowledge of just how "q gets changed" can rescue the situation. In strongly-typed languages, for example, if x and z are different data types, we know the assignment of z through q can't affect x. We also know that the assignment can't affect x if x and z have disjoint scopes. The 'restrict' keyword in C pointer declarations was added to help mitigate this problem. Some compilers also have a command line option that allows the user to say, "I solemnly swear that I won't do this sort of thing". -Paul W.