On Mon, Mar 5, 2012 at 10:00 AM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Mon, 5 Mar 2012, Arnaldo wrote: > >> I couldn't get cfgexpand.c:basic_block expand_gimple_basic_block >> (basic_block bb) to work by calling it directly because there is some >> preprocessing in gimple_expand_cfg() that has to be done first. But >> calling gimple_expand_cfg() modifies the CFG and asserts will fail later >> on during compilation. >> >> I think the only way to solve this would be to somehow duplicate the >> current cfun structure when entering the part of Graphite I'm extending, >> then calling push_cfun(), gimple_expand_cfg(), extracting the BBs with >> the RTL and calling pop_cfun() before continuing. > > Really, you're barking up the wrong tree. graphite doesn't work on the > RTL IL, it'll work only on gimple. expanding is what we call the process > of transforming gimple to RTL, and that process destroys gimple. Hence > you can't do that when still at the gimple side of things as there are > still passes to run that run in gimple. > > Whatever you want to do with graphite, you have to do it at the gimple > level. > > > Ciao, > Michael.
Richard, Michael, I have to find a way to generate the RTL because I have profiled an instruction set and I need access to these costs during my extension to the Graphite pass. I planed to add these costs as attributes to the RTX patterns in the machine description file and read the back from Graphite. Gimple seems to be too high-level to associate its statements to machine costs. I know this is not the way GCC was designed but the optimization I'm working on needs access to the profile. Maybe there's a better way of doing this? What I'm attempting to do now is to duplicate the current cfun so that I can expand and read the RTL attributes and then discard this cfun before continuing with the compilation. -Arnaldo
