------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
