This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Basic Block Statistics


On Wed, May 17, 2017 at 2:59 PM, Will Hawkins <whh8b@virginia.edu> wrote:
> On Wed, May 17, 2017 at 2:41 PM, Will Hawkins <whh8b@virginia.edu> wrote:
>> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins <whh8b@virginia.edu> wrote:
>>> On Wed, May 17, 2017 at 1:02 PM, Jeff Law <law@redhat.com> wrote:
>>>> On 05/17/2017 10:36 AM, Will Hawkins wrote:
>>>>> As I started looking into this, it seems like PLUGIN_FINISH is where
>>>>> my plugin will go. Everything is great so far. However, when plugins
>>>>> at that event are invoked, they get no data. That means I will have to
>>>>> look into global structures for information regarding the compilation.
>>>>> Are there pointers to the documentation that describe the relevant
>>>>> global data structures that are accessible at this point?
>>>>>
>>>>> I am looking through the source code and documentation and can't find
>>>>> what I am looking for. I am happy to continue working, but thought I'd
>>>>> ask just in case I was missing something silly.
>>>>>
>>>>> Thanks again for all your help getting me started on this!
>>>> FOR_EACH_BB (bb) is what you're looking for.  That will iterate over the
>>>> basic blocks.
>>>
>>> Thank you so much for your response!
>>>
>>> I just found this as soon as you sent it. Sorry for wasting your time!
>>>
>>>
>>>>
>>>> Assuming you're running late, you'll then want to walk each insn within
>>>> the bb.  So something like this
>>>>
>>>> basic_block bb
>>>> FOR_EACH_BB (bb)
>>>>   {
>>>>     rtx_insn *insn;
>>>>     FOR_BB_INSNS (bb, insn)
>>>>       {
>>>>         /* Do something with INSN.  */
>>>>       }
>>>>   }
>>>>
>>>>
>>>> Note that if you're running too late the CFG may have been released, in
>>>> which case this code wouldn't do anything.
>>
>> This macro seems to require that there be a valid cfun. This seems to
>> imply that the macro will work only where the plugin callback is
>> invoked before/after a pass that does some optimization for a
>> particular function. In particular, at PLUGIN_FINISH, cfun is NULL.
>> This makes perfect sense.
>>
>> Since PLUGIN_FINISH is the place where diagnostics are supposed to be
>> printed, I was wondering if there was an equivalent iterator for all
>> translation units (from which I could derive functions, from which I
>> could derive basic blocks) that just "FINISH"ed compiling?
>
>
> Answering my own question for historical purposes and anyone else who
> might need this:
>
>   FOR_EACH_VEC_ELT(*all_translation_units, i, t)
>
> is exactly what I was looking for!
>
> Sorry for the earlier spam and thank you for your patience!
> Will


Well, I thought that this was what I wanted, but it turns out perhaps
I was wrong. So, I am turning back for some help. Again, i apologize
for the incessant emails.

I would have thought that a translation unit tree node's chain would
point to all the nested tree nodes. This does not seem to be the case,
however. Am I missing something? Or is this the intended behavior?

Again, thank you for your patience!
Will

>
>>
>> The other way to approach the problem, I suppose, is to just
>> accumulate those stats at the end of each pass execution phase and
>> then simply print them when PLUGIN_FINISH is invoked.
>>
>> I'm sorry to make this so difficult. I am just wondering about the way
>> that the community expects the plugins to be written in the most
>> modular fashion.
>>
>> Thanks again for walking me through all this!
>> Will
>>
>>>
>>> I will just have to experiment to see exactly when the right time to
>>> invoke this plugin to get the best data.
>>>
>>> Thanks again!
>>> Will
>>>
>>>>
>>>> jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]