RFC: Gimple combine/folding interface

[Marc Glisse]

On Fri, 19 Jul 2013, Andrew Pinski wrote:

> I was creating a new gimple/folding interface

Thanks.

> and wanted some opinions on the interface.
>
> typedef double_int (*nonzerobits_t)(tree var);
> typedef tree (*valueizer_t)(tree var);
>
> class gimple_combine
> {
> public:
>  gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
> valueizerv(b), allow_full_reassiocation(false) {}
>  gimple_combine() : nonzerobitsf(NULL), valueizerv(NULL),
> allow_full_reassiocation(false) {}
>  gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
> allow_full_reassiocation(reas) {}
>  tree build2 (location_t, enum tree_code, tree, tree, tree);
>  tree build1 (location_t, enum tree_code, tree, tree);
>  tree build3 (location_t, enum tree_code, tree, tree, tree, tree);
>  tree combine (gimple);
> private:
>  nonzerobits_t nonzerobitsf;
>  valueizer_t valueizerv;
>  bool allow_full_reassiocation;
>  tree binary (location_t, enum tree_code, tree, tree, tree);
>  tree unary (location_t, enum tree_code, tree, tree);
>  tree ternary (location_t, enum tree_code, tree, tree, tree, tree);
> };
>
> bool replace_rhs_after_ssa_combine (gimple_stmt_iterator *, tree);
>
> This is what I have so far and wonder if there is anything else I
> should include.
>
> This will be used to replace the folding code in fold-const.c and 
> gimple-fold.c.

And half of tree-ssa-forwprop.c ?

replace_rhs_after_ssa_combine:
- does "after" mean it is somehow delayed, or just that it is meant to be 
called right after combine?
- is the return value an indication that some cleanup is needed?
- does it re-gimplify its argument if it isn't a valid gimple rhs?

Would the valueizer be limited to single use variables? Depending on the 
transformation, we may want to restrict to single use or not.

It would be possible to use a single name instead of build1, build2, 
build3 (either with overloading or with default argument values).

Not sure it should be called gimple_combine since with a trivial valueizer 
it would be a generic tree folder (maybe the combine function could be 
overloaded so it can take a tree and replace fold?).

It may be convenient to forbid valueizerv==0 and use instead a trivial one 
that just returns its argument, so we don't have to test if valueizer 
exists everytime we use it.

With this interface, we will build trees and immediatly convert them to 
gimple and forget them. That doesn't seem easy to avoid...

No folding categories as in 
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01099.html ?

-- 
Marc Glisse