Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux?

Kaz Kylheku <221-501-9011@kylheku.com>
Thu, 8 Sep 2016 22:54:13 +0000 (UTC)

          From comp.compilers

Related articles
Alternative C compilers on x86_64 Linux? arnold@skeeve.com (2016-09-02)
Re: Alternative C compilers on x86_64 Linux? bc@freeuk.com (BartC) (2016-09-05)
Re: Alternative C compilers on x86_64 Linux? 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-06)
Re: Alternative C compilers on x86_64 Linux? bc@freeuk.com (BartC) (2016-09-06)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-08)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-08)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-09)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-09)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu gneuner2@comcast.net (George Neuner) (2016-09-09)
Re: dead code or otherwise, was Alternative C compilers on x86_64 Linu 221-501-9011@kylheku.com (Kaz Kylheku) (2016-09-09)
| List of all articles for this month |

From: Kaz Kylheku <221-501-9011@kylheku.com>
Newsgroups: comp.compilers
Date: Thu, 8 Sep 2016 22:54:13 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 16-09-001 16-09-005 16-09-009 16-09-012 16-09-015
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="43074"; mail-complaints-to="abuse@iecc.com"
Keywords: C, optimize
Posted-Date: 08 Sep 2016 20:44:29 EDT

On 2016-09-08, George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 6 Sep 2016 21:35:30 +0100, BartC <bc@freeuk.com> wrote:
>
>>On 06/09/2016 03:15, Kaz Kylheku wrote:
>>
>>> A duplicate condition in an if-else chain is unreachable code, which is
>>> probably a bug.
>>>
>>> if (foo) {
>>> ...
>>> } else if (foo) {
>>> /* unreachable */
>>> } else if (bar) {
>>> ...
>>> }
>>
>>It's not necessarily unreachable. For example:
>>
>> if (foo()) { ...}
>> elsif if (foo()) { ... }
>>
>>foo() could return false the first time and true the second time.
>
> In such cases foo doesn't need to be function - it only needs to be a
> [moral equivalent of a C] volatile to exhibit strange behavior.


Two occurrences of an impure expression aren't the same condition.


If a compiler wants to rearrange the code so that the result of such
an expression is to appear in multiple places (where in the original
source language, the corresponding expression appears just once), it
must introduce a temporary variable to hold the result, and propagate
the variable. Otherwise the multiple evaluations will lead to
unpleasant surprised.


      ;; poor: copies of code fragment (foo) literally proliferated


    (let ((code-fragment '(foo))
                (temp (gensym)))
        `(cond (,code-fragment ...)
                      (,code-fragment ...) ;; not same; potentially reachable!
                          ...)))


    ;; correct:


    (let ((code-fragment '(foo))
                (temp (gensym)))
        `(let ((,temp ,code-fragment)) ;; eval code fragment to temporary
              (cond (,temp ...) ;; proliferate temporary
                          (,temp ...) ;; unreachable!
                          ...)))


Anyway, this was originally about translating C switch statements, where
the conditions are pure expressions, being integer constants. "else if
(foo()) ..." is an unlikely translation of a standard C switch case.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.