This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gimplefe] Parsing PHI functions
- From: Prasad Ghangal <prasad dot ghangal at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 1 Jul 2016 17:27:15 +0530
- 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>
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?
>
> Richard.
>>
>>
>>
>> Thanks,
>> Prasad