https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100235

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Priority|P3                          |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Mark J Olah from comment #0)
> I am observing a significant compile time increase for gfortran-10.3.0, when
> computing math intrinsic operations over arrays constructed at compile-time.
> 
> ======= Test case =========
> 
> #define N 8000
> PROGRAM TEST
> 
> REAL :: V(0:N)
> V  = ACOS( (/ (I, I=0,N) /)/100000.0 )
> 
> END PROGRAM
> 

Using a sane value for N such as 4 and adding -fdump-tree-original to the
command line reveals

gfortran 10.2.0

% gfortran -fdump-tree-orginal -o z a.F90
% more a.F90.004t.original

test ()
{
  integer(kind=4) i;
  real(kind=4) v[5];

  {
    static real(kind=4) A.0[5] = {0.0, 9.99999974737875163555145263671875e-6,
1.99999994947575032711029052734375e-5, 2.999999924213625490665435791015625e-5,
3.9999998989515006542205810546875e-5};

    {
      integer(kind=8) S.1;

      S.1 = 0;
      while (1)
        {
          if (S.1 > 4) goto L.1;
          v[S.1] = __builtin_acosf (A.0[S.1]);
          S.1 = S.1 + 1;
        }
      L.1:;
    }
  }
}


For top-of-tree gfortran, one finds

% gfcx -o z -fdump-tree-original a.F90
% more z-a.F90.005t.original 
__attribute__((fn spec (". ")))
void test ()
{
  integer(kind=4) i;
  real(kind=4) v[11];

  {
    static real(kind=4) A.0[11] = {1.57079637050628662109375e+0,
1.57078635692596435546875e+0, 1.57077634334564208984375e+0,
1.57076632976531982421875e+0, 1.57075631618499755859375e+0,
1.57074630260467529296875e+0, 1.57073628902435302734375e+0,
1.57072627544403076171875e+0, 1.570716381072998046875e+0,
1.57070636749267578125e+0, 1.570696353912353515625e+0};

    (void) __builtin_memcpy ((void *) &v, (void *) &A.0, 44);
  }
}

So, what we have learned is that for 10.2.x and older, gfortran does not
evaluate ACOS().  In newer versions of gfortran, the compiler will perform
the evaluation of ACOS() at compile time, and this is done with MPFR.
So, yeah, it's slower because the compiler is doing more work.

Bug should likely be closed with WONTFIX.  Someone else can make that decision.

Reply via email to