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? 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)
