This is the mail archive of the 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;

  a_2 = 3;
  goto bb_4;

  a_3 = 6;
  goto bb_4;

  a_1 = __PHI (bb_2: a_2, bb_3: a_3);
  a_1 = a_1 + 1;

On 1 July 2016 at 17:33, Richard Biener <> wrote:
> On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal <> wrote:
>> On 29 June 2016 at 12:42, Richard Biener <> wrote:
>>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>>> <> 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]