[PATCH]: PR29335 use MPFR for builtin sincos

Richard Guenther richard.guenther@gmail.com
Wed Nov 1 18:43:00 GMT 2006

On 11/1/06, Roger Sayle <roger@eyesopen.com> wrote:
> On Wed, 1 Nov 2006, Richard Guenther wrote:
> >> This might transform a valid gimple statement into a non-gimple one - did
> >> you verify that the various places that might fold the statement correctly
> >> handle this case?
> This has come up in discussions previously, and goes to the architectural
> design of how fold and tree-ssa are supposed to interoperate.
> My current understanding is that the fold functions are allowed to
> return non-gimple results (and often do) even for gimple input trees.
> This both simplifies the code (especially in fold-const.c) and allows
> more flexibility.  The pass invoking fold_builtin/fold can trivially
> determine whether the tree was modified (via pointer equality), or
> test whether the result is valid gimple (as is done in set_rhs in
> tree-ssa-propagate.c).  I believe the current tree-ssa solution is
> that folded results are currently ignored if they are non-gimple
> after stripping useless type conversions.  The obvious improvement
> would be to re-gimplify into the statement list, which has been
> discussed several times but never implemented (IIRC).  Likewise,
> with the intention of making better use of fold in tree-ssa-ccp.c and
> out-of-ssa.
> See http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00232.html
> Most of the small handful of checks for in_gimple_form in fold-const.c
> and builtins.c date back to before the current API "contract" was
> decided and agreed upon.  In fact, I'll investigate removing many
> of them as a clean-up, now that we're back in stage 1.
> Hopefully, everyone still agrees this approach is sensible?  However,

Yes, this is the only sensible thing.  I just was sure some basic testing
was done - sincos is not a too widely used function, so we'd probably
notice late if something breaks.

> even so, just because the tree-ssa optimizers are supposed to be aware
> of non-gimple results from fold, doesn't mean they actually are.  I
> think the idea of adding a testcase or two along the lines you propose
> [where the tree isn't folded in the front-end], would make excellent
> sanity checks.  In fact, I'd be curious to see whether your suggested
> "sincos(zero,...)" would even get simplified before RTL expansion with
> Kaveh's patch.

The constant propagation should happen at least for
-funsafe-math-optimization - I believe but did not check.


More information about the Gcc-patches mailing list