Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
On 20 May 2015 at 17:39, Prathamesh Kulkarni
prathamesh.kulka...@linaro.org 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 ?
Bootstrap failed with -Werror=parantheses . Applied the attached patch
(which just adds { } on if (p p-is_oper_list))
Thanks,
Prathamesh
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)
Index: genmatch.c
===
--- genmatch.c (revision 223610)
+++ genmatch.c (working copy)
@@ -2913,7 +2913,12 @@
user_id *p = dyn_castuser_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;
}
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
On Wed, 20 May 2015, Prathamesh Kulkarni wrote: On 20 May 2015 at 18:18, Richard Biener rguent...@suse.de wrote: 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. 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'. Yes, but I think this use is confusing as to whether the operator lists form a new for (like currently(?)) or if they append to the enclosing for. What we do currently is consistent (always create a new for) but it is confusing behavior - as you noted initially. Richard. 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 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) -- Richard Biener rguent...@suse.de SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
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' ? 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 -;( Thanks, Prathamesh OK for trunk after bootstrap+testing ? Thanks, Prathamesh
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
On Wed, 20 May 2015, Prathamesh Kulkarni wrote: Hi, This patch rejects expanding operator-list to implicit 'for'. OK for trunk after bootstrap+testing ? Ok. Thanks, Richard.
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
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)
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
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 ? 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) 2015-05-20 Prathamesh Kulkarni prathamesh.kulka...@linaro.org * genmatch.c (parser::parse_operation): Reject expanding operator-list inside 'for'. Index: genmatch.c === --- genmatch.c (revision 223437) +++ genmatch.c (working copy) @@ -2913,7 +2913,10 @@ user_id *p = dyn_castuser_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; }
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
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)
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
On 20 May 2015 at 18:18, Richard Biener rguent...@suse.de wrote: 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. 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 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)
