| Message ID | CAAgBjMkN_cEqiZ2eJKPEStumViYUffCZ+nwvjFs5C=qgaaAJxA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 20 May 2015 at 18:18, Richard Biener <rguenther@suse.de> wrote: > On Wed, 20 May 2015, Prathamesh Kulkarni wrote: > >> On 20 May 2015 at 17:01, Richard Biener <rguenther@suse.de> wrote: >> > 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. Well I suppose we could extend it to be mixed with 'for' ? Add the operator lists to the inner-most 'for'. eg: (define_operator_list olist ...) (for op (...) (simplify (op (olist ...)))) would be equivalent to: (for op (...) temp (olist) (simplify (op (olist ...)))) operator-list expansion can be said to simply a short-hand for single 'for' with number of iterators = number of operator-lists. If the operator-lists are enclosed within 'for', add them to the innermost 'for'. Thanks, Prathamesh >> > >> >> 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 <rguenther@suse.de> >> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) >> > > -- > Richard Biener <rguenther@suse.de> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
Index: genmatch.c =================================================================== --- genmatch.c (revision 223437) +++ genmatch.c (working copy) @@ -2913,7 +2913,10 @@ user_id *p = dyn_cast<user_id *> (op); if (p && p->is_oper_list) - record_operlist (id_tok->src_loc, p); + if (active_fors.length() == 0) + record_operlist (id_tok->src_loc, p); + else + fatal_at (id_tok, "operator-list %s cannot be exapnded inside 'for'", id); return op; }