This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Basic Block Statistics
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!
Will
On Tue, May 16, 2017 at 2:54 PM, Jeff Law <law@redhat.com> wrote:
> On 05/16/2017 12:37 PM, Will Hawkins wrote:
>> On Tue, May 16, 2017 at 2:33 PM, Jeff Law <law@redhat.com> wrote:
>>> On 05/16/2017 12:24 PM, Will Hawkins wrote:
>>>> Hello everyone!
>>>>
>>>> I apologize if this is not the right venue to ask this question and/or
>>>> this is a waste of your time.
>>>>
>>>> I was just wondering if there are statistics that gcc can emit that
>>>> includes either a) the average number of instructions per basic block
>>>> and/or b) the average size (in bytes) per basic block in a compilation
>>>> unit.
>>>>
>>>> If nothing like this exists, I am more than happy to code something up
>>>> if people besides me think that it might be interesting.
>>>>
>>>> I promise that I googled for information before asking, but I can't
>>>> guarantee that I didn't miss anything. Again, I apologize if I just
>>>> needed to RTFM better.
>>> I don't think we have anything which inherently will give you this
>>> information.
>>>
>>> It'd be a useful thing to have though. Implementation may be made more
>>> difficult by insns that generate > 1 instruction.
>>>
>>> Jeff
>>
>> Thank you, Mr. Law. I think that this is something I'd really like to
>> work on. As I start to take a peak into how hard/easy this is to
>> implement, I may circle back and ask some additional technical
>> questions.
> Sure. On-list is best.
> Jeff