Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: David Brown Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior Date: Mon, 29 Apr 2019 00:12:14 +0200 Organization: A noiseless patient Spider Lines: 57 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-04-038@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-024@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="20499"; mail-complaints-to="abuse@iecc.com" Keywords: optimize Posted-Date: 28 Apr 2019 18:36:15 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Content-Language: en-GB Xref: csiph.com comp.compilers:2222 On 26/04/2019 04:26, Kaz Kylheku wrote: > On 2019-04-25, David Brown wrote: >> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true. > > Also, we could have it so that multiplication wraps, and yet in the same > breath allow algebraic reductions like this anyway. > > Basically it can be so that, if overflow takes place in the abstract > semantics of "x * 2 / 2", the result can be either the truncated > version, or just x, if the algebraic reduction took place. > I am afraid I don't understand you here. Are you saying that you could define the language's arithmetic so that, given "x * 2 / 2", the compiler could return /either/ "x" or the result you would get from wrapped overflow calculations? You are defining two possible "correct" answers? > Algebraic reductions that can change the result can be confined > to evaluation regions similar to (perhaps tied to) sequence points, > such that if we write: > > int y = x * 2; > int z = y / 2; > > then the calculations are belabored; z is not reduced to x. > Note that in C, as defined by the standards (whether you agree with them or not), sequence points do not cause any such effects. z can be reduced to x. > Anyway, anyone who wants "x * 2 / 2" to be reduced to "x" through layers > of macrology can always use a more sophisticated macro processor. Parse > it, build a tree, and do the optimization in the preprocessor. > I find the C preprocessor to be quite sophisticated. And I find compiler optimisation, such as inline and constant propagation, to be even more sophisticated. Sometimes I use additional pre-processing or code generation for specialist use, but I am happy not to need it for this kind of thing. > C should serve as a stable "higher level assembly" target for that sort > of thing. No, C should serve as a stable "higher level language" - not an assembly. If you want to have a "higher level assembly", then you can make that from C - typically the usage of unsigned types rather than signed types will give you most of what you want here. A liberal sprinkling of "volatile" is also useful in such use-cases. And, if you really want to, it's not hard to write something like: #ifdef __GNUC__ #pragma GCC optimize -fwrapv #endif