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: RFC: Gimple combine/folding interface


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


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