This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gimplefe] Parsing PHI functions


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;
}





On 1 July 2016 at 17:33, Richard Biener <richard.guenther@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>> On 29 June 2016 at 12:42, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>>> <prasad.ghangal@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

Attachment: test.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]