This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <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'.

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]