* Iterating over RTL in Graphite @ 2012-02-17 9:53 Arnaldo 2012-02-17 22:52 ` David Malcolm 0 siblings, 1 reply; 12+ messages in thread From: Arnaldo @ 2012-02-17 9:53 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-02-17 9:53 Iterating over RTL in Graphite Arnaldo @ 2012-02-17 22:52 ` David Malcolm 2012-02-18 10:37 ` Tobias Grosser 0 siblings, 1 reply; 12+ messages in thread From: David Malcolm @ 2012-02-17 22:52 UTC (permalink / raw) To: Arnaldo; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-02-17 22:52 ` David Malcolm @ 2012-02-18 10:37 ` Tobias Grosser 2012-02-18 22:54 ` Arnaldo 0 siblings, 1 reply; 12+ messages in thread From: Tobias Grosser @ 2012-02-18 10:37 UTC (permalink / raw) To: David Malcolm; +Cc: Arnaldo, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-02-18 10:37 ` Tobias Grosser @ 2012-02-18 22:54 ` Arnaldo 2012-03-05 13:51 ` Arnaldo 0 siblings, 1 reply; 12+ messages in thread From: Arnaldo @ 2012-02-18 22:54 UTC (permalink / raw) To: Tobias Grosser; +Cc: David Malcolm, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-02-18 22:54 ` Arnaldo @ 2012-03-05 13:51 ` Arnaldo 2012-03-05 13:58 ` Richard Guenther 2012-03-05 14:00 ` Michael Matz 0 siblings, 2 replies; 12+ messages in thread From: Arnaldo @ 2012-03-05 13:51 UTC (permalink / raw) To: Tobias Grosser; +Cc: David Malcolm, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 13:51 ` Arnaldo @ 2012-03-05 13:58 ` Richard Guenther 2012-03-05 14:00 ` Michael Matz 1 sibling, 0 replies; 12+ messages in thread From: Richard Guenther @ 2012-03-05 13:58 UTC (permalink / raw) To: Arnaldo; +Cc: Tobias Grosser, David Malcolm, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 13:51 ` Arnaldo 2012-03-05 13:58 ` Richard Guenther @ 2012-03-05 14:00 ` Michael Matz 2012-03-05 14:52 ` Arnaldo 1 sibling, 1 reply; 12+ messages in thread From: Michael Matz @ 2012-03-05 14:00 UTC (permalink / raw) To: Arnaldo; +Cc: Tobias Grosser, David Malcolm, gcc 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 14:00 ` Michael Matz @ 2012-03-05 14:52 ` Arnaldo 2012-03-05 14:58 ` Richard Guenther 2012-03-05 15:24 ` David Edelsohn 0 siblings, 2 replies; 12+ messages in thread From: Arnaldo @ 2012-03-05 14:52 UTC (permalink / raw) To: Michael Matz; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 14:52 ` Arnaldo @ 2012-03-05 14:58 ` Richard Guenther 2012-03-05 15:24 ` David Edelsohn 1 sibling, 0 replies; 12+ messages in thread From: Richard Guenther @ 2012-03-05 14:58 UTC (permalink / raw) To: Arnaldo; +Cc: Michael Matz, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 14:52 ` Arnaldo 2012-03-05 14:58 ` Richard Guenther @ 2012-03-05 15:24 ` David Edelsohn 2012-03-05 15:31 ` Arnaldo 1 sibling, 1 reply; 12+ messages in thread From: David Edelsohn @ 2012-03-05 15:24 UTC (permalink / raw) To: Arnaldo; +Cc: Michael Matz, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 15:24 ` David Edelsohn @ 2012-03-05 15:31 ` Arnaldo 2012-03-05 15:37 ` Richard Guenther 0 siblings, 1 reply; 12+ messages in thread From: Arnaldo @ 2012-03-05 15:31 UTC (permalink / raw) To: David Edelsohn; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Iterating over RTL in Graphite 2012-03-05 15:31 ` Arnaldo @ 2012-03-05 15:37 ` Richard Guenther 0 siblings, 0 replies; 12+ messages in thread From: Richard Guenther @ 2012-03-05 15:37 UTC (permalink / raw) To: Arnaldo; +Cc: David Edelsohn, gcc 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-03-05 15:37 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-17 9:53 Iterating over RTL in Graphite Arnaldo 2012-02-17 22:52 ` David Malcolm 2012-02-18 10:37 ` Tobias Grosser 2012-02-18 22:54 ` Arnaldo 2012-03-05 13:51 ` Arnaldo 2012-03-05 13:58 ` Richard Guenther 2012-03-05 14:00 ` Michael Matz 2012-03-05 14:52 ` Arnaldo 2012-03-05 14:58 ` Richard Guenther 2012-03-05 15:24 ` David Edelsohn 2012-03-05 15:31 ` Arnaldo 2012-03-05 15:37 ` Richard Guenther
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).