Thanks,
Prasad
On 29 July 2016 at 12:55, Richard Biener <richard.guent...@gmail.com> wrote:
> On Fri, Jul 29, 2016 at 9:03 AM, Prasad Ghangal
> <prasad.ghan...@gmail.com> wrote:
>> Thanks,
>> Prasad
>>
>>
>> On 29 July 2016 at 06:56, Prathamesh Kulkarni
>> <prathamesh.kulka...@linaro.org> wrote:
>>> On 29 July 2016 at 00:01, Prasad Ghangal <prasad.ghan...@gmail.com> wrote:
>>>> On 27 July 2016 at 14:22, Richard Biener <richard.guent...@gmail.com>
>>>> wrote:
>>>>> On Tue, Jul 26, 2016 at 11:38 PM, Prathamesh Kulkarni
>>>>> <prathamesh.kulka...@linaro.org> wrote:
>>>>>> On 27 July 2016 at 00:20, Prasad Ghangal <prasad.ghan...@gmail.com>
>>>>>> wrote:
>>>>> There is one other feature missing for SSA name parsing (forget to
>>>>> mention that)
>>>>> which is parsing of default def SSA names. Those are for example used for
>>>>> parameters and currently dumped like
>>>>>
>>>>> foo (int i)
>>>>> {
>>>>> int D.1759;
>>>>> int _2;
>>>>>
>>>>> <bb 2>:
>>>>> _2 = i_1(D) + 1;
>>>>> return _2;
>>>>> }
>>>>>
>>>>> for int foo (int i) { return i + 1; }. Here 'i_1(D)' is the
>>>>> default-def of 'i' which
>>>>> in case of a parameter is the value at function start and in case of a
>>>>> non-parameter
>>>>> is simply "undefined". '(D)' is again somewhat awkward to parse but I
>>>>> guess we
>>>>> can cope with that ;) A default-def needs to be registered like
>>>>>
>>>>> arg = make_ssa_name_fn (cfun, lookup_name (id), ...);
>>>>> set_ssa_default_def (cfun, lookup_name (id), arg);
>>>>>
>>>>> "undefined" SSA names appear often in PHIs (and of course for parameters).
>>>>>
>>>>
>>>> This updated patch tries to parse default def ssa names
>>> Um does this emit error for cases like a_1() and a_(D) ?
>>> From the code it appears to me that parsing 'D' is made optional, so
>>> id_version() would be accepted.
>>> Perhaps have an else for the if (!strcmp("D", ...) that emits parse error ?
>>>
>> Right. Currently it gives ICE but we can handle it with better way.
>>
>>> Btw for the following case:
>>> int a;
>>> int a_1;
>>> int x = a_1 + 1;
>>> What does a_1 refer to in "int x = a_1 + 1" ? the ssa-version of 'a'
>>> or the variable 'a_1' ?
>>> I think from the code it would refer to ssa-version of a ? However the
>>> reference looks
>>> ambiguous to me (since we also allow variables in non-ssa form).
>>>
>> we are guarding it with condition
>> if (TREE_CODE (c_parser_peek_token (parser)->value) == IDENTIFIER_NODE
>> && !lookup_name (c_parser_peek_token (parser)->value))
>> so that shouldn't happen.
>
> Note that the example is indeed ambiguous. As said previously rejecting all
> invalid source shouldn't be necessarily scope of the GSoC project. In this
> particular case the issue is from using _ as the separator for the SSA name
> version - the source simply has to cope with that (or we need to choose sth
> else). Similar issue is that a_1(D) can also parse as a function call in C.
>
> Btw, I'd like to see some testcases for the SSA name parsing in the testsuite.
>
I have added testcases for __PHI and ssa names
Thanks,
Prasad
> Thanks,
> Richard.
>
>>
>> Thanks,
>> Prasad
>>
>>> Thanks,
>>> Prathamesh
>>>>
>>>> Thanks,
>>>> Prasad
>>>>
>>>>> Thanks,
>>>>> Richard.
>>>>>
>>>>>> Thanks,
>>>>>> Prathamesh
>>>>>>>
>>>>>>> for testcase :
>>>>>>>
>>>>>>> void __GIMPLE () foo()
>>>>>>> {
>>>>>>> int a;
>>>>>>> bb_2:
>>>>>>> if (a > 4)
>>>>>>> goto bb_3;
>>>>>>> else
>>>>>>> goto bb_4;
>>>>>>> bb_3:
>>>>>>> a_1 = 55;
>>>>>>> goto bb_5;
>>>>>>>
>>>>>>> bb_4:
>>>>>>> a_2 = 99;
>>>>>>>
>>>>>>> bb_5:
>>>>>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2);
>>>>>>> a_4 = a_3 + 3;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> I am getting ssa dump as:
>>>>>>>
>>>>>>> /* Function foo (foo, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
>>>>>>> symbol_order=0)*/
>>>>>>>
>>>>>>> void
>>>>>>> foo ()
>>>>>>> {
>>>>>>> bb_2:
>>>>>>> if (a_5 > 4)
>>>>>>> goto bb_3;
>>>>>>> else
>>>>>>> goto bb_4;
>>>>>>>
>>>>>>> bb_3:
>>>>>>> a_1 = 55;
>>>>>>> goto bb_5;
>>>>>>>
>>>>>>> bb_4:
>>>>>>> a_2 = 99;
>>>>>>>
>>>>>>> a_3 = __PHI (bb_3: a_1, bb_4: a_2)
>>>>>>> bb_5:
>>>>>>> a_4 = a_3 + 3;
>>>>>>> return;
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Prathamesh
>>>>>>>>>>
>>>>>>>>>> Richard.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Richard.
>>>>>>>>>>>>
>>>>>>>>>>>>>Dave
>>>>>>>>>>>>
>>>>>>>>>>>>
