This is the mail archive of the
mailing list for the GCC project.
Re: [gimplefe] Parsing PHI functions
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Prasad Ghangal <prasad dot ghangal at gmail dot com>
- Cc: gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 1 Jul 2016 14:03:49 +0200
- Subject: Re: [gimplefe] Parsing PHI functions
- Authentication-results: sourceware.org; auth=none
- References: <CAE+uiWYGhK8+Y55zmVwZx_zTrdruTdrmShdp6=Z=5-Yc7Gipmw at mail dot gmail dot com> <CAFiYyc0CUH4fLkJDkshhXbN0gcXY6e2jpD+FKu2-E5Yq+O60uQ at mail dot gmail dot com> <CAE+uiWYOwdQEkHSPwrF-j6NT0CWXEq8bFvZZ+0eHE8AnCC-o0g at mail dot gmail dot com>
On Fri, Jul 1, 2016 at 1:57 PM, Prasad Ghangal <email@example.com> wrote:
> On 29 June 2016 at 12:42, Richard Biener <firstname.lastname@example.org> wrote:
>> On Tue, Jun 28, 2016 at 4:16 PM, Prasad Ghangal
>> <email@example.com> wrote:
>>> 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
>> to predecessor block labels, like
>> i_1 = 1;
>> goto p;
>> i_2 = 2;
>> goto 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).