This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: PR29335 use MPFR for builtin sincos
On 11/1/06, Roger Sayle <firstname.lastname@example.org> 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
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
The constant propagation should happen at least for
-funsafe-math-optimization - I believe but did not check.