Re: RFC: Gimple combine/folding interface

[Jeff Law <law at redhat dot com>]

On 07/21/2013 08:14 PM, Andrew Pinski wrote:
> On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> > I was creating a new gimple/folding interface 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),
IIRC, the zero/nonzero bits stuff in combine is mostly good at pruning 
sign/zero extensions, eliminating bit masking in the low bits for alphas 
and for cleaning up addressing of varargs arguments that were on the 
stack.  Yea, there are times when it can do other stuff, but that's my 
recollection for what it was actually good at.

Before designing an interface which inherently includes that information 
we should think hard about if it's valuable and if a tree combiner is 
the right place.

I have high hopes that we can get the zero/sign extension elimination we 
want by carrying VRP information and querying it.

As Richi has mentioned, we really want a folder we can call 
independently of whatever pass we're in.  Though I'd also like a folder 
that can query for pass specific information if it's handy and useful.

One of the interesting things we're going to need to figure out is when 
walking the use-def chains do we want to build the more complex 
expression, then fold it, keeping the result if it's gimple.  Or do we 
want to work strictly with an exploded operator/operands represenation.

Jeff