[Vm-dev] Removing UB to make SmallFloat handling gcc 4.9.2 -O2 compatible [WAS: first 64 bits windows VM Running]

[Nicolas Cellier]

2016-07-18 19:03 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> The recipe for compiling on windows: install cygwin and pretend it's
> unix...
> With Eliot's mvm scripts and gnu make, it's essentially same job on linux
> and macosx...
>
> Note that gcc 4.9.3 -O2 does not perform a good job...
> For example 2.0*3.0 answers 4.0 for the fast version (mvm -f).
> All is correct for the debug version (mvm -d).
>
> clang seems to be performing better, this means that we'll have to play
> with compiler options again...
> Or better: eliminate Undefined Behavior which is most probably the cause
> of problems
> (There is some in SmallFloat handling, shifting left negative int, pointer
> aliasing, etc...)
>
>
Note: i've successfully compiled Squeak stack spur 64 bits with gcc 4.9.2
-02 and restored the correct behavior for SmallFloat:
    2.0*3.0 correctly answer 6.0 instead of 4.0...

For that it's necessary to remove undefined behavior related to left
shifting an unsigned integer.

Instead of generating something like:
    ((sqLong) rcvr) << arg
It's better to generate it like this:
    (sqLong)(((usqLong) rcvr) ) << arg)

This way we preserve signedness and Behavior is well defined.
Since the formulation is rather heavy, I also added tricks to avoid some
casts if variable is long enough and unsigned already. If we later switch
longAt and some others as unsigned as already dicussed here, the generated
C might almost be readable.

I will commit the necessary VMMaker patch.

I've also replaced pointer aliasing
    doubleResult = (double *)( & rawBitsInteger )[0];
by memcpy:
    memcpy( &doubleResult  , &rawBitsInteger , sizeof(doubleResult) );

Why is memcpy less evil than pointer aliasing?
With pointer aliasing any other write into a long integer could modify
doubleResult.
This completely defeat optimization - the holy grail of C people, they
can't bother that FORTRAN compilers are faster than theirs ;). With great
wisdom they declared this construct as undefined behavior, giving priority
to optimization rather than backward compatibility or programmers'
intentions...
memcpy is less evil because it's localized (one shot).

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160719/775e4803/attachment.htm