[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.3                         |9.4

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 9.3.0 has been released, adjusting target milestone.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
I can reproduce the issue on my Debian machine. Do you know which values are
passed to MPC?

I've tried with

  mpc_init2 (x, 24);
  mpc_init2 (y, 24);
  mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
  mpc_tan (y, x, MPC_RNDNN);

including with a reduced exponent range, but this is very fast. And according
to ldd, the same versions of the GMP/MPFR/MPC libraries are used here with both
GCC and my MPC test.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
  mpc_tan (m, m, 0)

with

(gdb) p *m
$14 = {re = {{_mpfr_prec = 24, _mpfr_sign = 1, _mpfr_exp = 14, 
      _mpfr_d = 0x3713c48}}, im = {{_mpfr_prec = 24, _mpfr_sign = 1, 
      _mpfr_exp = 14, _mpfr_d = 0x3710278}}}
(gdb) p *m->re._mpfr_d@4
$36 = {11258999068426240000, 32, 81, 57753152}
(gdb) p *m->im._mpfr_d@4
$37 = {11258999068426240000, 32, 81, 57738592}

I guess there's only one limb, the rest looks garbage.  We're using
mpfr_set_str on the re/im part from "0x0.9c4p+14" here.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Richard Biener from comment #6)
> I guess there's only one limb, the rest looks garbage.

Yes, and 11258999068426240000 with _mpfr_exp = 14 corresponds to 10000 as
expected (11258999068426240000 = 10000*2^50).

And even when reusing the input

  mpc_init2 (x, 24);
  mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
  mpc_tan (x, x, 0);

the program terminates immediately.

I'm going to look at this more closely with gdb. But I confirm I can see
mpc_tan in the backtrace.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
The exponent range is important. With ltrace, I can see:

3472505 mpfr_set_emin(0xffffffffffff7f22, 0xffffbf92, 0xffffbf92, 46) = 0
3472505 mpfr_set_emax(0x8002, 0xffffbf92, 0x7fb7c2c9c420, 46) = 0

(BTW, this is buggy, mpfr_set_emin and mpfr_set_emax take one argument only).

And with these corresponding particular values

  mpfr_set_emin (-32990);
  mpfr_set_emax (32770);

my MPC test loops.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 1 Apr 2020, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
> 
> --- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> (In reply to Richard Biener from comment #6)
> > I guess there's only one limb, the rest looks garbage.
> 
> Yes, and 11258999068426240000 with _mpfr_exp = 14 corresponds to 10000 as
> expected (11258999068426240000 = 10000*2^50).
> 
> And even when reusing the input
> 
>   mpc_init2 (x, 24);
>   mpc_set_ui_ui (x, 10000, 10000, MPC_RNDNN);
>   mpc_tan (x, x, 0);
> 
> the program terminates immediately.
> 
> I'm going to look at this more closely with gdb. But I confirm I can see
> mpc_tan in the backtrace.

It's likely by us doing

mpfr_set_emin (-32990);
mpfr_set_emax (32766);

during startup to work around a similar bug in MPC (IIRC it also
was tan ...).

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #10 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to rguenther@suse.de from comment #9)
> It's likely by us doing
> 
> mpfr_set_emin (-32990);
> mpfr_set_emax (32766);
> 
> during startup to work around a similar bug in MPC (IIRC it also
> was tan ...).

I suspect an internal overflow in the MPC computation, in which case doubling
the precision at each iteration won't solve the issue. Setting emax to 14425 or
below avoids the loop, but the real part of the result is slightly incorrect (0
instead of non-zero), though not affecting the binary32 exponent range, as this
value is tiny:

  1.0011111100101111e-28854

Changing the exponent range will solve the issue for some values, but I fear
that whatever the exponent range is chosen, there may remain values that will
trigger the bug.

Paul Zimmermann says that this bug is fixed in the MPC development version.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #11 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #10)
> Paul Zimmermann says that this bug is fixed in the MPC development version.

I could check that the bug is actually fixed, but the does not solve the GCC
issue, as the time complexity is too large. With 10000000 instead of 10000,
you'll still notice that it takes too much time.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[vincent-gcc at vinc17 dot net]

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

--- Comment #12 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #11)
> (In reply to Vincent Lefèvre from comment #10)
> > Paul Zimmermann says that this bug is fixed in the MPC development version.
> 
> I could check that the bug is actually fixed, but the does not solve the GCC
> issue, as the time complexity is too large. With 10000000 instead of 10000,
> you'll still notice that it takes too much time.

But as Paul says, keeping the exponent range reduced as above allows an
immediate answer. So the solution will be to upgrade to the next MPC version
(not released yet) and do not increase the exponent range (this allows early
underflow/overflow checking, thus may avoid costly computations in some
domains).

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, thanks for digging into this. -> mpc bug