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

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


>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.


That certainly is true ... for some definition ... but in the examples
given by Bart and me, the compiler has no basis to distinguish the
occurrences.




>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!
> ...)))
>


Also true, but irrelevent. The compiler can't assume semantics not in
evidence. It's job is to faithfully translate the source as written
... not the source with better hygiene, and not the source as the
compiler thinks the programmer maybe intended.


Leaving aside for the moment what is legal in a C switch, if I tell
the compiler to call foo() multiple times, I expect it to do that.




>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.


But like any good Usenet discussion, it (d)evolved into something more
general.


Not every language with a CASE like construct has C's limitations on
specifying the alternatives. Lisp certainly doesn't. And it is
perfectly reasonable to implement the construct using an IF chain.


In fact, many (non-Lisp) compilers do implement CASE like constructs
using chained IF performing a binary search when the set of
alternatives is either sparse enough or large enough to make using a
dispatch table unweildy (or mostly empty).


George

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