On Mon, Mar 5, 2012 at 4:31 PM, Arnaldo <arnaldo.c...@upr.edu> wrote: > 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.
That of course is as inaccurate as a simple gimple-stmt based cost model. Because costs of loop (nests) on nearly every target depend on the insn scheduling and data access patterns, something which is not even modeled properly at the RTL level unless you are setting up the scheduling machinery. So I suggest you use estimate_num_insns[_seq] instead, eventually adjusting it to more closely match your target. Richard. > -Arnaldo
