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]

Re: [PATCH]: PR29335 use MPFR for builtin sincos


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,
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.


Of course, things may have changed and are always up for renegotiation.

Roger
--


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