On Mon, Mar 5, 2012 at 11:17 AM, David Edelsohn <dje....@gmail.com> wrote: > On Mon, Mar 5, 2012 at 9:52 AM, Arnaldo <arnaldo.c...@upr.edu> wrote: >> 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. > > You can look in the SSA loop optimizations (tree-ssa-loop-ivopts.c?) > for some code that basically compiles little snippets from GIMPLE to > RTL, computes RTX costs, and then tries to map those back to GIMPLE. > It's very ugly and limited accuracy. > > - David
David thanks that seems to be what I need, I'll look into that first. Richard, For each BB in an SCoP I could add the costs of its RTX to compute a cost for the BB and then transform the polyhedral matrices to try to estimate the program cost using different nested loop configurations. -Arnaldo