Re: Optimization techniques

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

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