On Sun, Jul 3, 2016 at 9:34 AM, Prasad Ghangal <prasad.ghan...@gmail.com> wrote:
> In this patch, I am passing labels and vars with internal function and
> handling them in tree-cfg for parsing PHI.
> For first label, label_to_block() gives correct basic block and I am
> getting proper edges but for other labels the function is giving NULL.
>
> test-case :
>
> void __GIMPLE () foo()
> {
> int a;
> int a_2;
> int a_3;
> int a_1;
>
> bb_2:
> a_2 = 3;
> goto bb_4;
>
> bb_3:
> a_3 = 6;
> goto bb_4;
>
> bb_4:
> a_1 = __PHI (bb_2: a_2, bb_3: a_3);
> a_1 = a_1 + 1;
> return;
> }
>
The issue is probably you lower PHIs after cleanup_tree_cfg is run which may
end up removing labels. Or it is cleanup_dead_labels in build_gimple_cfg.
Richard.
>
>
>
> On 1 July 2016 at 17:33, Richard Biener <richard.guent...@gmail.com> wrote:
>> On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal <prasad.ghan...@gmail.com>
>> wrote:
>>> On 29 June 2016 at 12:42, Richard Biener <richard.guent...@gmail.com> wrote:
>>>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>>>> <prasad.ghan...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> For handling PHI, it expects cfg to be built before. So I was
>>>>> wondering how are we going to handle this? Do we need to build cfg
>>>>> while parsing only?
>>>>
>>>> For handling PHIs we need to have a CFG in the sense that the GIMPLE PHI
>>>> data structures are built in a way to have the PHI argument index
>>>> correspond
>>>> to CFG predecessor edge index. As we'd like to parse phis with args
>>>> corresponding
>>>> to predecessor block labels, like
>>>>
>>>> a:
>>>> i_1 = 1;
>>>> goto p;
>>>>
>>>> b:
>>>> i_2 = 2;
>>>> goto p;
>>>>
>>>> p:
>>>> i_3 = __PHI (a: i_1, b: i_2);
>>>>
>>>> I think that a possibility is to leave those PHIs as internal function
>>>> with label / arg
>>>> pairs and have CFG construction lower them to real PHIs.
>>>>
>>>> Of course the parser could as well build a CFG on its own but I think
>>>> we should use
>>>> the easy way out for now.
>>>>
>>>> Thus you'd have to modify CFG construction a bit to lower the internal
>>>> function calls.
>>>
>>> Currently I am just building internal call using
>>> gimple_build_call_internal_vec (), and detecting (and removing for
>>> now) it after edge creation in tree-cfg. I was observing
>>> internal-fn.def, do I need to make entry in internal-fn.def and write
>>> expand function?
>>
>> You should add an entry and a stub expand function (like those
>> others that simply have gcc_unreachable in them).
>>
>> Richard.
>>
>>>>
>>>> Richard.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Prasad
