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
