Re: [match-and-simplify] reject expanding operator-list to implicit 'for'

[Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>]

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

Attachment: ChangeLog.txt
Description: Text document

Attachment: patch.txt
Description: Text document