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
