Re: Fix PR tree-optimization/20940

[Diego Novillo <dnovillo at redhat dot com>]

On Wed, Mar 16, 2005 at 10:23:38AM -0700, Roger Sayle wrote:

> Instead, a far more reasonable approach is to allow "fold" to do
> it's thing preserving type safety and improving code quality, then
> at the level immediately above, perhaps in a fold_gimple, check
> whether the result is suitable, and ignore any transformations that
> don't suit the current criteria.
> 
OK, good.

> In fact, to shoot down Diego's argument about fixing all the places
> that call fold_stmt, it turns out that fold_stmt already contains
>
You're shooting down the wrong argument.  My argument is that I
want a fold that guarantees a GIMPLE return value.  fold_stmt
already does that.

As we agreed on IRC, if you give us a gimple_fold that wraps
around fold, that will be enough.  In the couple of places where
we want to do the utmost, we call fold and deal with the
regimplification and SSA renaming afterwards.

> Of course, the tree-ssa optimizers would be much more powerful/
> effective, if instead of ignoring non-gimple results they instead
> regimplified the optimized results, inserting the appropriate
> assignments in the stmt stream.  Unfortunately, the APIs for doing
> this haven't yet been written, so the best tree-ssa can do is ignore
> any trees it doesn't understand.
> 
They are almost there, actually.  convert_to_gimple_builtin has most of
the smarts needed for the general case.

> And before finishing my rant, I'll just answer a question that should
> be confusing some people.  How does transforming "x * -1" into "-x",
>
Yes, in_gimple_form needs to disappear from fold.


Diego.