Re: Iterating over RTL in Graphite

[Arnaldo <arnaldo.cruz@upr.edu>]

On Mon, Mar 5, 2012 at 11:17 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Mon, Mar 5, 2012 at 9:52 AM, Arnaldo <arnaldo.cruz@upr.edu> wrote:
>> On Mon, Mar 5, 2012 at 10:00 AM, Michael Matz <matz@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