This is the mail archive of the gcc-patches@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: Embedd bitmaps into dataflow problem structures


> On 06/04/2010 03:00 PM, Jan Hubicka wrote:
>> Hi,
>> dataflow datastructures are quite pointer heavy and since we collect a lot
>> of cache misses looking up bitmap headers and most of those are accounted to
>> dataflow, I decided to try to reduce amount of indirection here to improve
>> locality.
>>
>> This is first step, putting bitmap into the problem structures as bitmap_headers.
>> This saves one pointer and two obstack allocations and does not cost memory since
>> we allocate the outer structure always together with all the bitmaps I believe.
>>
>> cc1 WHOPR build is now 10m38 seconds, before patch I measured always over 10m50
>> seconds.
>
> That's 1.5% -- whoa.
>
> This is obviously okay. :-)

Thanks for quick reply! I will progress with further flattening then.

Can I ask you about the flattening of block_info array?
Since we keep basic_block indexes dense, I guess I would not be scared of
extra memory overhead for unused indexes.
I wonder what the API sould be.  Currently there is 
  /* Array indexed by bb->index, that contains basic block problem and
     solution specific information.  */
  void **block_info;
that is allocated at df_grow_bb_info and we have accestor functions.

I guess making this to allocate chunks of specific size is easy,
or should I go for union of VEC_tors for specific problems in df-problem structure?

>
>> I wonder if someone tested putting the df-problems bitmaps into specific
>> obstacks that are deallocated when problem is done?  It might help a bit with
>> locality: the main bitmap obstack get completely mixed via freelists very soon.
>
> I thought Steven did that, but the code says he didn't. :-)

OK, will give this a try next then.
>
>> I am also attaching the promised partial inlining bitmap patch.
>
> What's the performance improvement from that?

none at the moment, we are cache bound. But it makes oprofiling more informative
and if we get out of cache constraints, it might be useful.

Honza
>
> Paolo


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