Iterating over RTL in Graphite

Iterating over RTL in Graphite

[Arnaldo]

Hello everyone,

I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
intention is to associate costs to RTL instructions by adding them as
RTX attributes to a machine description file, and to read them back
during the Graphite pass by iterating through each basic block.

Is the RTL available during this optimization pass? I'm not sure this
is the case as I get a segfault when trying to iterate over the RTL
with the code below ("internal compiler error: Segmentation fault"). I
don't need the fully resolved RTL, just to be able to read the
attribute given an RTL instruction.

I've tried debugging the compiler with gdb but it can't find the
debugging symbols even though they're there.  I'll keep trying to get
gdb to work but any leads on reading these attributes from within
Graphite is greatly appreciated.

-Arnaldo


Code to iterate over RTL
-----------------------------------
graphite_bb_p gbb;
rtx insn;
int i;

for (i = 0; VEC_iterate (graphite_bb_p, SCOP_BBS (scop), i, gbb); i++)
{
    if (GBB_BB(gbb))
        for (insn = BB_HEAD (GBB_BB(gbb)); insn != NEXT_INSN (BB_END
(GBB_BB(gbb))); insn = NEXT_INSN (insn))
            if (INSN_P (insn))
                fprintf(dump_file, "RTL detected\n");
}


Test code
--------------
unsigned int image[N+K][N+K];
unsigned int filter[K][K];
unsigned int out[N][N];

// Init arrays ...

int main()
{
    int v = 0;
    int h = 0;
    int i = 0;
    int j = 0;
    unsigned int s = 0;

    for (v = 0; v < N; v++)
        for (h= 0; h < N; h++)
        {
            s = 0;
            for (i = 0; i < K; i++)
                for (j = 0; j < K; j++)
                    s += image[v+i][h+j] * filter[i][j];

            out[v][h] = s >> FACTOR;
        }

    return 0;
}


Compilation flags
-----------------
arm-unknown-eabi-gcc -O0 -mabi=aapcs-linux -mcpu=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -fno-math-errno -fno-signed-zeros
-fno-tree-vectorize -Wall -I../../..//lib -I../../../ -O2 -floop-block
-floop-interchange -floop-strip-mine -ftree-vectorize
-fvect-cost-model -ftree-vectorizer-verbose=3 -fdump-tree-all
-fdump-rtl-expand   -c -o convolve.o convolve.c

Re: Iterating over RTL in Graphite

[David Malcolm]

On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
> Hello everyone,
> 
> I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
> intention is to associate costs to RTL instructions by adding them as
> RTX attributes to a machine description file, and to read them back
> during the Graphite pass by iterating through each basic block.
> 
> Is the RTL available during this optimization pass? I'm not sure this
> is the case as I get a segfault when trying to iterate over the RTL
> with the code below ("internal compiler error: Segmentation fault"). I
> don't need the fully resolved RTL, just to be able to read the
> attribute given an RTL instruction.
> 
> I've tried debugging the compiler with gdb but it can't find the
> debugging symbols even though they're there.  I'll keep trying to get
> gdb to work but any leads on reading these attributes from within
> Graphite is greatly appreciated.
I don't know about GCC 4.4, but a while back I wrote a script using my
GCC Python plugin to draw a "subway map" of GCC 4.6's passes:
http://gcc.gnu.org/ml/gcc/2011-07/msg00157.html
which you can see here:
http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html

If I reading things correctly, the graphite passes happen whilst the
code is still in gimple form: the blocks are converted to RTL form in
the "expand" pass, which happens about 20 or so passes later.

Caveat: I'm not familiar with the insides of the graphite, and am
relatively new to gcc's insides, so I could be wrong; also the script
relies on the pass flags, and they're not necessarily correct either...

Hope this is helpful
Dave

Re: Iterating over RTL in Graphite

[Tobias Grosser]

On 02/17/2012 08:34 PM, David Malcolm wrote:
> On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
>> Hello everyone,
>>
>> I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
>> intention is to associate costs to RTL instructions by adding them as
>> RTX attributes to a machine description file, and to read them back
>> during the Graphite pass by iterating through each basic block.
>>
>> Is the RTL available during this optimization pass? I'm not sure this
>> is the case as I get a segfault when trying to iterate over the RTL
>> with the code below ("internal compiler error: Segmentation fault"). I
>> don't need the fully resolved RTL, just to be able to read the
>> attribute given an RTL instruction.
>>
>> I've tried debugging the compiler with gdb but it can't find the
>> debugging symbols even though they're there.  I'll keep trying to get
>> gdb to work but any leads on reading these attributes from within
>> Graphite is greatly appreciated.
> I don't know about GCC 4.4, but a while back I wrote a script using my
> GCC Python plugin to draw a "subway map" of GCC 4.6's passes:
> http://gcc.gnu.org/ml/gcc/2011-07/msg00157.html
> which you can see here:
> http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
>
> If I reading things correctly, the graphite passes happen whilst the
> code is still in gimple form: the blocks are converted to RTL form in
> the "expand" pass, which happens about 20 or so passes later.
>
> Caveat: I'm not familiar with the insides of the graphite, and am
> relatively new to gcc's insides, so I could be wrong; also the script
> relies on the pass flags, and they're not necessarily correct either...

Yes, graphite works on GIMPLE. I believe I have never seen RTL when 
working on graphite, so I doubt it is easily available. (Maybe it is, 
but it is definitely not used within graphite).

Cheers
Tobi

Re: Iterating over RTL in Graphite

[Arnaldo]

On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser <tobias@grosser.es> wrote:
> On 02/17/2012 08:34 PM, David Malcolm wrote:
>>
>> On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
>>>
>>> Hello everyone,
>>>
>>> I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
>>> intention is to associate costs to RTL instructions by adding them as
>>> RTX attributes to a machine description file, and to read them back
>>> during the Graphite pass by iterating through each basic block.
>>>
>>> Is the RTL available during this optimization pass? I'm not sure this
>>> is the case as I get a segfault when trying to iterate over the RTL
>>> with the code below ("internal compiler error: Segmentation fault"). I
>>> don't need the fully resolved RTL, just to be able to read the
>>> attribute given an RTL instruction.
>>>
>>> I've tried debugging the compiler with gdb but it can't find the
>>> debugging symbols even though they're there.  I'll keep trying to get
>>> gdb to work but any leads on reading these attributes from within
>>> Graphite is greatly appreciated.
>>
>> I don't know about GCC 4.4, but a while back I wrote a script using my
>> GCC Python plugin to draw a "subway map" of GCC 4.6's passes:
>> http://gcc.gnu.org/ml/gcc/2011-07/msg00157.html
>> which you can see here:
>> http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
>>
>> If I reading things correctly, the graphite passes happen whilst the
>> code is still in gimple form: the blocks are converted to RTL form in
>> the "expand" pass, which happens about 20 or so passes later.
>>
>> Caveat: I'm not familiar with the insides of the graphite, and am
>> relatively new to gcc's insides, so I could be wrong; also the script
>> relies on the pass flags, and they're not necessarily correct either...
>
>
> Yes, graphite works on GIMPLE. I believe I have never seen RTL when working
> on graphite, so I doubt it is easily available. (Maybe it is, but it is
> definitely not used within graphite).
>
> Cheers
> Tobi
>

Thanks David and Tobias, that helped.

I started looking into the expand pass (cfgexpand.c), there's an
interesting function there:
static basic_block expand_gimple_basic_block (basic_block bb)

When I get a change I'll make it 'public' and see if I can call it
from graphite.c

-Arnaldo

Re: Iterating over RTL in Graphite

[Arnaldo]

On Sat, Feb 18, 2012 at 6:46 PM, Arnaldo <arnaldo.cruz@upr.edu> wrote:
> On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser <tobias@grosser.es> wrote:
>> On 02/17/2012 08:34 PM, David Malcolm wrote:
>>>
>>> On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
>>>> intention is to associate costs to RTL instructions by adding them as
>>>> RTX attributes to a machine description file, and to read them back
>>>> during the Graphite pass by iterating through each basic block.
>>>>
>>>> Is the RTL available during this optimization pass? I'm not sure this
>>>> is the case as I get a segfault when trying to iterate over the RTL
>>>> with the code below ("internal compiler error: Segmentation fault"). I
>>>> don't need the fully resolved RTL, just to be able to read the
>>>> attribute given an RTL instruction.
>>>>
>>>> I've tried debugging the compiler with gdb but it can't find the
>>>> debugging symbols even though they're there.  I'll keep trying to get
>>>> gdb to work but any leads on reading these attributes from within
>>>> Graphite is greatly appreciated.
>>>
>>> I don't know about GCC 4.4, but a while back I wrote a script using my
>>> GCC Python plugin to draw a "subway map" of GCC 4.6's passes:
>>> http://gcc.gnu.org/ml/gcc/2011-07/msg00157.html
>>> which you can see here:
>>> http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
>>>
>>> If I reading things correctly, the graphite passes happen whilst the
>>> code is still in gimple form: the blocks are converted to RTL form in
>>> the "expand" pass, which happens about 20 or so passes later.
>>>
>>> Caveat: I'm not familiar with the insides of the graphite, and am
>>> relatively new to gcc's insides, so I could be wrong; also the script
>>> relies on the pass flags, and they're not necessarily correct either...
>>
>>
>> Yes, graphite works on GIMPLE. I believe I have never seen RTL when working
>> on graphite, so I doubt it is easily available. (Maybe it is, but it is
>> definitely not used within graphite).
>>
>> Cheers
>> Tobi
>>
>
> Thanks David and Tobias, that helped.
>
> I started looking into the expand pass (cfgexpand.c), there's an
> interesting function there:
> static basic_block expand_gimple_basic_block (basic_block bb)
>
> When I get a change I'll make it 'public' and see if I can call it
> from graphite.c
>
> -Arnaldo

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.

-Arnaldo

Re: Iterating over RTL in Graphite

[Richard Guenther]

On Mon, Mar 5, 2012 at 2:51 PM, Arnaldo <arnaldo.cruz@upr.edu> wrote:
> On Sat, Feb 18, 2012 at 6:46 PM, Arnaldo <arnaldo.cruz@upr.edu> wrote:
>> On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser <tobias@grosser.es> wrote:
>>> On 02/17/2012 08:34 PM, David Malcolm wrote:
>>>>
>>>> On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
>>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I'm working on an extension to the Graphite pass of GCC 4.4.0.  My
>>>>> intention is to associate costs to RTL instructions by adding them as
>>>>> RTX attributes to a machine description file, and to read them back
>>>>> during the Graphite pass by iterating through each basic block.
>>>>>
>>>>> Is the RTL available during this optimization pass? I'm not sure this
>>>>> is the case as I get a segfault when trying to iterate over the RTL
>>>>> with the code below ("internal compiler error: Segmentation fault"). I
>>>>> don't need the fully resolved RTL, just to be able to read the
>>>>> attribute given an RTL instruction.
>>>>>
>>>>> I've tried debugging the compiler with gdb but it can't find the
>>>>> debugging symbols even though they're there.  I'll keep trying to get
>>>>> gdb to work but any leads on reading these attributes from within
>>>>> Graphite is greatly appreciated.
>>>>
>>>> I don't know about GCC 4.4, but a while back I wrote a script using my
>>>> GCC Python plugin to draw a "subway map" of GCC 4.6's passes:
>>>> http://gcc.gnu.org/ml/gcc/2011-07/msg00157.html
>>>> which you can see here:
>>>> http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
>>>>
>>>> If I reading things correctly, the graphite passes happen whilst the
>>>> code is still in gimple form: the blocks are converted to RTL form in
>>>> the "expand" pass, which happens about 20 or so passes later.
>>>>
>>>> Caveat: I'm not familiar with the insides of the graphite, and am
>>>> relatively new to gcc's insides, so I could be wrong; also the script
>>>> relies on the pass flags, and they're not necessarily correct either...
>>>
>>>
>>> Yes, graphite works on GIMPLE. I believe I have never seen RTL when working
>>> on graphite, so I doubt it is easily available. (Maybe it is, but it is
>>> definitely not used within graphite).
>>>
>>> Cheers
>>> Tobi
>>>
>>
>> Thanks David and Tobias, that helped.
>>
>> I started looking into the expand pass (cfgexpand.c), there's an
>> interesting function there:
>> static basic_block expand_gimple_basic_block (basic_block bb)
>>
>> When I get a change I'll make it 'public' and see if I can call it
>> from graphite.c
>>
>> -Arnaldo
>
> 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.

Why would you want to look at RTL from graphite at all??  That seems
to be completely bogus and pointless.

Richard.

> -Arnaldo

Re: Iterating over RTL in Graphite

[Michael Matz]

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.

Re: Iterating over RTL in Graphite

[Arnaldo]

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.

-Arnaldo

Re: Iterating over RTL in Graphite

[Richard Guenther]

On Mon, Mar 5, 2012 at 3:52 PM, 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.

Graphite (polyhedral form) is even more high-level, how do you expect
RTX costs to be meaningful there at all?

> 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.

I don't even see how you could compute a reliable mapping of Graphite
(or GIMPLE) to the RTL you generate that way.

Richard.

> -Arnaldo

Re: Iterating over RTL in Graphite

[David Edelsohn]

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

Re: Iterating over RTL in Graphite

[Arnaldo]

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

Re: Iterating over RTL in Graphite

[Richard Guenther]

On Mon, Mar 5, 2012 at 4:31 PM, Arnaldo <arnaldo.cruz@upr.edu> wrote:
> 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.

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