This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch Preview/RFC] tree-optimization/57994: Constant folding of infinity


Hi,

this is just a preview, but I decided to send it out early to understand if I'm on the right track or not. As you can see in the Bug, this started as a spin-off of a library issue with complex pow, which led us to:

    __builtin_exp(-__builtin_huge_val())

not being folded to a constant at compile-time. The reason is simple: the various do_mpfr_arg*, etc, all check real_isfinite on the arguments. In the audit trail of the bug we came to the conclusion that allowing non-NANs could make sense (the mpfr facilities appear to be quite solid in this case - maybe for NANs too, at least in the non-complex case, but that's another story). However, when today I started fiddling with this kind of change, I noticed that isn't enough for the kind of code we really care about for the original issue, involving logs too, thus something like:

  long double num = __builtin_logl(0L);
  long double res = __builtin_expl(num);

because the log isn't folded at all for zero: fold_builtin_logarithm calls do_mpfr_arg1 with true as last argument. We can make progress if, when it's safe - is !flag_trapping_math && !flag_errno_math enough? - we pass true instead. Then we also have to tweak do_mpfr_ckconv, because it checks mpfr_number_p (and real_isfinite) on the result of the folding, thus ruling out infinities. Then we are almost there: the latter can be actually fully folded if -O1 is used, -O0 is not Ok, because otherwise num isn't const propagated to the evaluation of res. Is this so far by and large Ok? I'm attaching a corresponding patchlet (it of course lacks testcases and testsuite adjustments)

Note: in the patchlet I'm not trying to handle NaNs; neither complex numbers; neither bessel, remquo and lgamma (which could probably be added?) Also, I suppose we could discover other cases like fold_builtin_logarithm, where, in the context of folding infinities too, we may have to tweak a bit the way do_mpfr_* functions are called

Thanks!
Paolo.

PS: there are interesting issues about the non-compile-time constant case, especially vs long double, which I didn't touch here.

////////////////////////



Attachment: p3
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]