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