Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: dead code or otherwise, was Alternative C compilers on x86_64 Linux? Date: Fri, 09 Sep 2016 00:51:55 -0400 Organization: A noiseless patient Spider Lines: 86 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <16-09-017@comp.compilers> References: <16-09-001@comp.compilers> <16-09-005@comp.compilers> <16-09-009@comp.compilers> <16-09-012@comp.compilers> <16-09-015@comp.compilers> <16-09-016@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="83576"; mail-complaints-to="abuse@iecc.com" Keywords: C, optimize Posted-Date: 09 Sep 2016 00:54:47 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1756 On Thu, 8 Sep 2016 22:54:13 +0000 (UTC), Kaz Kylheku <221-501-9011@kylheku.com> wrote: >On 2016-09-08, George Neuner wrote: >> On Tue, 6 Sep 2016 21:35:30 +0100, BartC 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