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]

Re: strange top statistics for 3.1 cc1


Colin Douglas Howell <chowell2@pacbell.net> writes:

> Daniel Berlin wrote:
> > 
>> Yummy.
>> This one is easy, for once.
>> And it's got to be where all the excessive cpu usage is coming from.
>> Excluding verify_flow_info (whenever i hit it, i jumped to the end of
>> the function), i hit split_all_insns in 4:38 of cpu time on my
>> powerbook.
>> What happens is split_all_insns calls find_sub_basic_blocks on each
>> basic block.
>> find_sub_basic_blocks calls make_edges.
>> make_edges makes an edge cache. an sbitmap vector that is
>> n_basic_blocks * n_basic_blocks. 9423 sbitmaps with 9423 bits in each.
>> (9423 * 9423) / 8 = 11,099,116 bytes.
>> There's your 11 meg sbitmap..
>> Now remember, it does this for every basic block.
>> 
>> So we create and destroy 11 meg 9423 times.
>
> I didn't take the time to trace through the details of what was
> happening, but this sounds consistent with what I saw.
>
> You say that this is where all the excessive CPU usage is coming from,
> but I only observed about 5% system CPU usage over the whole
> compilation, while during this phase, system CPU usage was about 50%.
> That implies that this phase consumed about 10% of the total CPU time.
> You also said you excluded verify_flow_info.  I haven't profiled the
> compiler, but that function also seemed be eating lots of CPU time.
>
> (This probably won't be successfully Cc'd to the list, due to ISP
> lameness.)
verify_flow_info only is called if ENABLE_CHECKING is on.
It's turned off in released compilers.


-- 
"My friend has a baby.  I'm recording all the noises he makes so
later I can ask him what he meant.
"-Steven Wright


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