This is the mail archive of the
mailing list for the GCC project.
Re: Iterating over RTL in Graphite
- From: Arnaldo <arnaldo dot cruz at upr dot edu>
- To: Tobias Grosser <tobias at grosser dot es>
- Cc: David Malcolm <dmalcolm at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 5 Mar 2012 09:51:36 -0400
- Subject: Re: Iterating over RTL in Graphite
- References: <CAB=90XDwy+H3q4BfMVOeVb7BRHHD=_Ju4iV-k6E7hsqaNWzxZg@mail.gmail.com> <1329507251.15787.25.camel@surprise> <4F3F09A5.firstname.lastname@example.org> <CAB=90XDPXDizzODHM5Kgt0EGSb8gaBR_MMm8EBBm=H60gNTVCQ@mail.gmail.com>
On Sat, Feb 18, 2012 at 6:46 PM, Arnaldo <email@example.com> wrote:
> On Fri, Feb 17, 2012 at 10:15 PM, Tobias Grosser <firstname.lastname@example.org> 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:
>>> which you can see here:
>>> 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).
> 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
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.