gnat 4.4.5 generates surprising code when enabling FP checks

gnat 4.4.5 generates surprising code when enabling FP checks

[Markus Schöpflin]

The behaviour described below has been observed for gcc 4.3.5, 4.4.5, and 
gnatpro 6.3.2, maybe someone here has any insight on this.

Given the following short code snippet:

procedure FLOAT_CHECKS is
    F1, F2, F3 : SHORT_FLOAT;
begin
    for I in 1..100_000 loop
       for J in 1..10_000 loop
          F1 := SHORT_FLOAT(I);  -- *
          F2 := SHORT_FLOAT(J);  -- *
          F3 := F1 * F2;         -- *
       end loop;
    end loop;
end FLOAT_CHECKS;

Compiling with gnatmake -O3 -gnatDG -gnatVa float_checks.adb gives the 
following intermediate code for the lines marked with '*':

          f1 := short_float({i});
          f2 := short_float({j});
          [constraint_error when
            not boolean!($system__fat_sflt__attr_short_float.
              system__fat_sflt__attr_short_float__valid (f1'
              unrestricted_access, xF => 0))
            "invalid data"]
          [constraint_error when
            not boolean!($system__fat_sflt__attr_short_float.
              system__fat_sflt__attr_short_float__valid (f2'
              unrestricted_access, xF => 0))
            "invalid data"]
          [constraint_error when
            not boolean!($system__fat_sflt__attr_short_float.
              system__fat_sflt__attr_short_float__valid (f1 * f2'
              unrestricted_access, xF => 0))
            "invalid data"]
          f3 := f1 * f2;

So far so good. What really surprises me is that in the resulting assembler 
code the last multiplication is actually performed twice, the disassembled 
object code looks like this (for the last check and multiplication only):

  8048ed6:       d9 45 e4                flds   -0x1c(%ebp)
  8048ed9:       d8 4d e0                fmuls  -0x20(%ebp)
  8048edc:       c7 44 24 04 00 00 00    movl   $0x0,0x4(%esp)
  8048ee3:       00
  8048ee4:       89 3c 24                mov    %edi,(%esp)
  8048ee7:       d9 5d dc                fstps  -0x24(%ebp)
  8048eea:       e8 61 fc ff ff          call   8048b50 
<system__fat_sflt__attr_short_float__valid@plt>
  8048eef:       84 c0                   test   %al,%al
  8048ef1:       74 2c                   je     8048f1f 
<_ada_float_checks+0xaf>
  8048ef3:       83 c3 01                add    $0x1,%ebx
  8048ef6:       d9 45 e4                flds   -0x1c(%ebp)
  8048ef9:       81 fb 11 27 00 00       cmp    $0x2711,%ebx
  8048eff:       d8 4d e0                fmuls  -0x20(%ebp)
  8048f02:       dd d8                   fstp   %st(0)

Is the second multiplication to be expected? Does anybody know if there is 
an optimizer option which would eliminate the second multiplication?

Regards,
Markus

Re: gnat 4.4.5 generates surprising code when enabling FP checks

[Georg Bauhaus]

On 07.04.11 17:48, Markus Schï¿œpflin wrote:
> What really surprises me is that in the resulting assembler
> code the last multiplication is actually performed twice, the disassembled
> object code looks like this (for the last check and multiplication only):

(I noticed that a big portion of the code is for performing
the validity checks requested via -gnatVa; lots of detail
documented in function Valid's body in System.Fat_Gen
(that I do not fully understand).  system__fat_sflt__attr_short_float__valid
refers to an instance of Fat_Gen (Short_Float), a package that
implements floating point attribute functions, IIUC.

(I also noticed that there is a conditional jump after
the call on system__fat_sflt__attr_short_float__valid
to after the second multiplication.)

>  8048ed6:       d9 45 e4                flds   -0x1c(%ebp)
>  8048ed9:       d8 4d e0                fmuls  -0x20(%ebp)
>  8048edc:       c7 44 24 04 00 00 00    movl   $0x0,0x4(%esp)
>  8048ee3:       00
>  8048ee4:       89 3c 24                mov    %edi,(%esp)
>  8048ee7:       d9 5d dc                fstps  -0x24(%ebp)
>  8048eea:       e8 61 fc ff ff          call   8048b50
> <system__fat_sflt__attr_short_float__valid@plt>
>  8048eef:       84 c0                   test   %al,%al
>  8048ef1:       74 2c                   je     8048f1f <_ada_float_checks+0xaf>
>  8048ef3:       83 c3 01                add    $0x1,%ebx
>  8048ef6:       d9 45 e4                flds   -0x1c(%ebp)
>  8048ef9:       81 fb 11 27 00 00       cmp    $0x2711,%ebx
>  8048eff:       d8 4d e0                fmuls  -0x20(%ebp)
>  8048f02:       dd d8                   fstp   %st(0)
> 
> Is the second multiplication to be expected? Does anybody know if there is an
> optimizer option which would eliminate the second multiplication?

Since much of the generated code is a consequence of -gnatVA
(which implies -gnatVf), shouldn't a smaller selection validity
checking do the trick, i.e. if you exclude -gnatVf?

Of course this doesn't answer the question if -gnatVa must be used.
HTH

Re: gnat 4.4.5 generates surprising code when enabling FP checks

[Markus Schöpflin]

Am 07.04.2011 19:10, schrieb Georg Bauhaus:

> Since much of the generated code is a consequence of -gnatVA
> (which implies -gnatVf), shouldn't a smaller selection validity
> checking do the trick, i.e. if you exclude -gnatVf?

The point was to have floating point validity checks on, so using -gnatVaF 
unfortunately is not an option.

The project in question used gcc 3.4 and was migrated to a newer gnat 
version, resulting in a serious performance degradation which I'm currently 
investigating.

I think I found the option which is responsible for the degradation (it's 
-gnatVc which is implied by -gnatVa and whose behaviour seems to have 
changed significantly for gcc 4.x).

The thing that surprised me was that the multiplication is actually 
performed twice, I was kind of expecting it to be only done once.

Currently I'm thinking of taking a step backwards and check what the 
project really needs in terms of validity checks in order to catch invalid 
floats (INFs and NAN) as soon as possible.

It looks like using 'type FLOAT_T is new FLOAT range FLOAT'Range' instead 
of unchecked IEEE floats with -gnatVa generates significantly better 
assembler code, so we might be able to just use -gnatVfpr instead.

Regards,
Markus