On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > On 20 May 2015 at 17:01, Richard Biener <rguent...@suse.de> wrote: > > On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > > > >> On 20 May 2015 at 16:17, Prathamesh Kulkarni > >> <prathamesh.kulka...@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? > This patch rejects expanding operator-list inside 'for'. > OK for trunk after bootstrap+testing ?
Ok. Thanks, Richard. > Thanks, > Prathamesh > > > > Thanks, > > Richard. > > > > > >> Thanks, > >> Prathamesh > >> > OK for trunk after bootstrap+testing ? > >> > > >> > Thanks, > >> > Prathamesh > >> > >> > > > > -- > > Richard Biener <rguent...@suse.de> > > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, > > Graham Norton, HRB 21284 (AG Nuernberg) > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
