🚀 go-pugleaf

In article <2557@mindlink.UUCP> a563@mindlink.UUCP (Dave Kirsch) writes:
>> aviv@discus.technion.ac.il writes:
>>    The only conclusion for us was : DON'T USE JUMP OPTIMIZATION !
>>    (or may be any other optimization ??)
>>    It can INSERT BUGS into your code.
>> 
>>    Until now, we did not find other bugs.
>> 
>>    And you ???
>
>If you look in the manual (and this appears on both TC and MSC manuals), there
>are warnings that optimizations will cause some code to break.  Specificly, in
>the TC 2.0 manual, there is a whole section on warning about use register
>optimization (not register variables).  This problem would seem to be related
>to register optimization, not jump optimization.  Does -O indicate to TC++ that
>it should do register optimization as well?
>
>Any optimizations will cause code to "break".  I assume somehow you didn't have
>register optimization on in TC 2.0 (you probably just had jump optimization).
>I suppose that if you took this same code to TC 2.0 and turned ON register
>optimization (O/C/O/R in the IDE or -Z on the command line) this code would
>probably not function; as you have indicated.
>
>It's not a bug, it's due to optimization, which any compiler warns you about
>when you read about enabling optimizations.

Sorry, but I don't agree with you. Although there are cases in which
a poorly written code can lead to an incorrect optimization (mainly in
code that has ALIASING), the optimization in a compiler is supposed to
improve code quality (object size or execution speed or both) not to
break working code. There are some programs that cannot be tested
estensively (i.e. doing number crunching, with a number as output: one
cannot certainly try them for all the possible input values) but
nevertless written in a plain, not tricky constructs of the language. If
the optimizer breaks this code (just because the manual warns about
"problems" in optimization) I think that the optimizer is generally useless.

I want to use (supposed bug free) programs which work, not that might work
if the optimizer is not too bad.
This does not mean that the compiler cannot be bugged (almost all programs
have bugs or problems), but I don't agree to assume that optimization leads
or can leads to bugged code. A good optimizer is like a good compiler: it
produce good output (=not bugged) code when compiling well written
input code (=no tricks, no aliasing, ...).

It is clear that if in TC one tries to use built-in register variables
(= _Ax, _BX, ..) and on the same time optimize register usage (= -z
option) there are very good chances that the output code is bugged. But,
again, this is tricky code, and, in addition, outside of the standard of
the language. Same applies while interfacing C to assembler, if the latter
does not follow the TC convention about register saving, etc.

In conclusion, optimization in a compiler, if provided, must produce as good
code as the main part of the compiler, otherwise it is useless.

antonio pastore
antoniop@cernvax.cern.ch

Having spent some time debugging optimizers, I would like to point out
that changing the optimization level changes the semantics of the
language being accepted by the compiler and therefor the code
generated.

A good compiler will document the new assumptions made about code so
that a compiler user will be able to determine if they are appropriate
for the code being optimized, but all compilers generate code for
slightly different languages when the optimizer is on than when it is
off.

Consider the pre ANSI handling of 'volatile' variables.  Turning
register optimization on is telling the compiler that you do not use
volatile variables and that it can determine the liveness of automatic
variables by looking at the local source code.  This will break
applications which depend on 'volatile' variables which are set
outside of the source code.

The "Bugs" that ensue usually fall into the niches left by the
standards writer for the compiler writer to implement.  Often a
compiler will handle an implementation defined behavior differently
when the optimizer is on than when it is off.   This is not a bug, but
a feature, since the standard allows the compiler writer to do so.
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa