Re: Iterating over RTL in Graphite
On Sat, Feb 18, 2012 at 6:46 PM, Arnaldo arnaldo.c...@upr.edu wrote: On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser tob...@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
On Mon, Mar 5, 2012 at 2:51 PM, Arnaldo arnaldo.c...@upr.edu wrote: On Sat, Feb 18, 2012 at 6:46 PM, Arnaldo arnaldo.c...@upr.edu wrote: On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser tob...@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
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
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
Re: Iterating over RTL in Graphite
On Mon, Mar 5, 2012 at 3:52 PM, 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. 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
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
Re: Iterating over RTL in Graphite
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
Re: Iterating over RTL in Graphite
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
Re: Iterating over RTL in Graphite
On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser tob...@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
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
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
Iterating over RTL in Graphite
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
