This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Basic Block Statistics
- From: Jeff Law <law at redhat dot com>
- To: Will Hawkins <whh8b at virginia dot edu>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 19 May 2017 14:40:30 -0600
- Subject: Re: Basic Block Statistics
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5ADB08553C
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5ADB08553C
- References: <CAE+MWFunCPEWzhmvOtuwo6L4C1vaS9r_L_eSHANx0fY8N2xgMw@mail.gmail.com> <60ef0242-a3ef-9d0c-5c9b-6cbe9c35305f@redhat.com> <CAE+MWFsUPwVY8V+edrEyS=1NWi_EZFQRE=QCUsjVwyGtDr=EHw@mail.gmail.com> <9c02d77c-246f-4584-7789-057563dd2aa4@redhat.com> <CAE+MWFvZ4nCadA5YFgBF-wOsPX=KXPrM8YC6O=nAGW-oxMxPKg@mail.gmail.com> <90a8b4a4-0883-0c7a-34ae-dae288fc6a6a@redhat.com> <CAE+MWFtqOKjqdc9DTpjgi8eZ2Zci0tBFcnaMS=ojGDSCL6n5XQ@mail.gmail.com> <CAE+MWFuHf6Yj=x-MMA6R3wrO4A7_Wzk7G0i5vUgKDKe1rhF+zA@mail.gmail.com> <CAE+MWFsv+w97aZn0LjboMyPQRiC57gkGvfpG+ET2gNTtnC=jfw@mail.gmail.com> <CAE+MWFsS+YpewfyLhU1hiL7qdxEJFXZDZa0mV=AYQJXiQEBEKQ@mail.gmail.com>
On 05/17/2017 08:22 PM, Will Hawkins wrote:
> 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?
I think there's a fundamental misunderstanding.
We don't hold the RTL IR for all the functions in a translation unit in
memory at the same time. You have to look at the RTL IR for each as its
generated.
jeff