Path: csiph.com!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Newsgroups: comp.compilers
Subject: Re: Optimization techniques
Date: Fri, 19 Apr 2019 11:48:52 -0400
Organization: Liberty Software Foundation
Lines: 39
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <19-04-010@comp.compilers>
References: <19-04-004@comp.compilers> <19-04-009@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="24525"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, design
Posted-Date: 19 Apr 2019 11:53:32 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-US
Xref: csiph.com comp.compilers:2194

On 4/19/2019 4:49 AM, Kaz Kylheku wrote:
> If you can make your language "C/C++ like" without all the undefined
> behavior looming at every corner (i.e. not actually "C/C++ like" at all
> in a significant regard), then you've dodged what is probably the number one
> optimization pitfall.

I think UB is unavoidable in any C/C++ language.  It is too low-level
for speed purposes to be bogged down with things that would prevent UB.
Even something simple like pointer use after free.  It can be difficult
to catch statically.

> For instance, don't have it so that the order of evaluation of
> function or operator arguments is unspecified. If you allow side-effects
> in expressions, specify when those effects take place in relation to
> everything else in the expression.
>
> If you have clear ordering rules, then you honor them when optimizing:
> you rearrange the user's calculation order only when it can't possibly
> make a difference to the result that is required by the defined
> order.

I do have very clear ordering rules.  I'm actually surprised to learn
that other systems do not.  I would've thought it would be absolutely
essential.

> Reordering arithmetic calculations has pitfalls. There are n! orders
> for adding together n numbers. Under floating-point, these all
> potentially return different results even if nothing overflows.
> You can't blindly rely on arithmetic identities to hold.

I think people who use floating point recognize it is not an exact
numbering system.

I have introduced native support for arbitrary precision integers
(bi) and floating point (bfp) to address this, but even then it's
still limited precision and not exact.

--
Rick C. Hodgin