[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

zadeck at naturalbridge dot com gcc-bugzilla@gcc.gnu.org
Thu Dec 20 01:57:00 GMT 2007



------- Comment #42 from zadeck at naturalbridge dot com  2007-12-20 01:56 -------
Subject: Re:  [4.3 regression] bad interaction between
 DF and SJLJ exceptions

steven at gcc dot gnu dot org wrote:
> ------- Comment #41 from steven at gcc dot gnu dot org  2007-12-19 23:57 -------
> Patches attached to this bug report address more general issues, namely:
>
> 1. The LIVE problem allocates too many bitmaps (xf. df_hack2.diff)
> 2. Large and very connected CFGs are a time problem
>
> Bug 26854 is another example of bad DF behavior, without SJLJ exceptions.  I'm
> making this bug depend on bug 26854 because bug 26854 shows there is more work
> to do than just fixing the above mentioned two issues.
>
> I suspect other problems than LIVE also allocate too many bitmaps.  We badly
> need a mechanism to track memory usage of DF.
>
>
>   
The df_hack2.diff actually allocates 1 more bitmap than without it.  the
space difference comes from the fact that a large number of the bitmaps
have fewer bits.  Remember that the implementation of bitmaps allocates
a block of memory for each 64 bit unit that contains some ones, so there
is a price paid in time and space for having more 1's in your maps.

the implementation of df actually uses 2 different memory allocation
frameworks.  The local data structures are based on alloc_pools and i do
not think that it would be hard to add a little code to this say how
many pools had been allocated.  However the bitmaps use obstacks which
are a completely different beast.   It would probably be best to just
convert bitmaps to use alloc pools since these seem to be better than
obstacks, but either way makes the accounting of space complex. 

I can work on the an addition to df_hack2.diff that does the same thing
for the reaching defs problem.  It will be a more tricky patch, but the
space gains may be even more significant because there are a lot more 1
bits flying thru the air in this problem.  As far as the time, doing
this will not make that much difference unless you are at -O2 or higher
since this is rarely (if at all) used at -O1.

Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400



More information about the Gcc-bugs mailing list