Re: [match-and-simplify] reject expanding operator-list to implicit 'for'

[Richard Biener <rguenther at suse dot de>]

On Wed, 20 May 2015, Prathamesh Kulkarni wrote:

> On 20 May 2015 at 16:17, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
> > Hi,
> > This patch rejects expanding operator-list to implicit 'for'.
> On second thoughts, should we reject expansion of operator-list _only_
> if it's mixed with 'for' ?

At least that, yes.

> We could define multiple operator-lists in simplify to be the same as
> enclosing the simplify in 'for' with number of iterators
> equal to number of operator-lists.
> So we could allow
> (define_operator_list op1 ...)
> (define_operator_list op2 ...)
> 
> (simplify
>   (op1 (op2 ... )))
> 
> is equivalent to:
> (for  temp1 (op1)
>        temp2 (op2)
>   (simplify
>     (temp1 (temp2 ...))))
> 
> I think we have patterns like these in match-builtin.pd in the
> match-and-simplify branch
> And reject mixing of 'for' and operator-lists.
> Admittedly the implicit 'for' behavior is not obvious from the syntax -;(

Hmm, indeed we have for example

/* Optimize pow(1.0,y) = 1.0.  */
(simplify
 (POW real_onep@0 @1)
 @0)

and I remember wanting that implicit for to make those less ugly.

So can you rework only rejecting it within for?

Thanks,
Richard.


> Thanks,
> Prathamesh
> > OK for trunk after bootstrap+testing ?
> >
> > Thanks,
> > Prathamesh
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)