This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
- From: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 20 May 2015 18:45:15 +0530
- Subject: Re: [match-and-simplify] reject expanding operator-list to implicit 'for'
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjMmHp+voXYijmt--sVt7-VDey84EtkO0Zd13HVimeyz+TQ at mail dot gmail dot com> <CAAgBjM=7VuoZrBAUGEd6xdUCejWEibdsqitVhbQzSkuNqaeLww at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1505201330270 dot 18702 at zhemvz dot fhfr dot qr> <CAAgBjMkN_cEqiZ2eJKPEStumViYUffCZ+nwvjFs5C=qgaaAJxA at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1505201448200 dot 18702 at zhemvz dot fhfr dot qr>
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)