------- Comment #9 from zadeck at naturalbridge dot com 2007-08-30 18:57 ------- Subject: Re: failing rtl iv analysis (maybe due to df)
zadeck at naturalbridge dot com wrote: > ------- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51 > ------- > Subject: Re: failing rtl iv analysis (maybe due > to df) > > rakdver at kam dot mff dot cuni dot cz wrote: > >> ------- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30 >> 18:09 ------- >> Subject: Re: failing rtl iv analysis (maybe due to df) >> >> >> >>> The only thing that you are allowed to do with the DF_REF_ID is to get >>> it from a df_def >>> AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION >>> >>> >> OK, this might be the problem; the code takes the defs from the reg->def >> lists, and checks whether the defs are set in the reaching def bitmaps. >> Naturally, it assumes that when the region is set by df_set_blocks, the >> reaching def bitmaps will only contain the defs that belong to the >> region (which used to be true before your changes). >> >> >> > And it is still true now. The set of bits in the bitmaps are EXACTLY > the set of defs inside the region. The thing that has changed is that > the location (slot) in the bitmap is only defined after the calls to > df_set_blocks and df_analyze, i.e. the slots in the bitvectors are moved > around by these calls. > > In your example, you asked about 2 defs. One of those defs is in the > region and one of them is outside the region. It is not that the bits > are zero for a def outside of the region, there is no slot in the > bitvectors that corresponds to that def in the bitvectors. You are not > allowed to look in the bitmap for the def outside of the region as ask > any questions at all if they involve the DF_REF_ID. For the def that is > in the region, you can ask but you cannot use the DF_REF_ID that it had > before the call to set_blocks. That old one is trash. > > What has changed, and this was a very old change, from the time that > danny still worked at ibm, was that the DF_REF_ID's are not stable and > the slots change after setting the blocks in the region. One of the > first df patches that was committed by us was to reorganize the bits so > that all of the refs for a single reg were contiguous. This gave a > factor of 7 speedup over the old code because it allowed for the use of > new bitmap operations that worked over dense range indexes. I assume > that this code has not really worked since then. > > >> Anyway, it would be nice to have some documentation for df (there >> is only a short notice in >> http://gcc.gnu.org/onlinedocs/gccint/Liveness-information.html#Liveness-information, >> which appears wrong given the importance of this api), in particular >> pointing out such non-obvious traps would be great. >> >> >> >> > This is only an issue if you use df_set_blocks and the only passes that > use it are these zdenek's loop passes. If I had my way (and infinite > free time) I would get rid of df_set_blocks anyway. The information > that it provides is generally wrong since it ignores information that > enters a block from the outside, but if you are very careful to only ask > a very limited range of questions, as Zdenek did, it can give you what > you want relatively inexpensively. > > Furthermore, it has been a real pain to keep it correct as the rest of > df has evolved. > > > > sorry zdenek, i misread who this was from, i would not have referred to you in the third person if i had read it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
