search for: clearallvaluemap

...ince they are public member variables of the ConstantBool class... If >>only everyone used the ConstantBool::get() there would be no problem, >>but that's not the case. Any suggestions? > > These should just be destroyed along with the rest of the constants, by > Constant::clearAllValueMaps. Hmmm, I was planning to call clearAllValueMaps once in a while to clear out the float constants which are building up on me... This shouldn't break anything as it stands, since the constants will be regenerated. However, deleting True and False will cause big problems. I think I'm ju...

...his -- there are some things you might not > like about it: > > 1) I had to make the private destroyConstantImpl method public to access > it from the template class ValueMap since there is no good way to > declare it as a friend. That's fine in principle, though if you make the clearAllValueMaps function be a static method in Type this is unneeded I think. > 2) I keep the types in a std::vector so I can easily drop all references > and delete them without going through all the type maps - this adds a > little bit of overhead, but there shouldn't be that many types (compared...

Chris Lattner wrote: > Ok, here's some feedback. This patch looks like a combination of several > different things. If you resubmit the patch in pieces, we can get the > undebatable ones applied first: > > 2. The clearAllValueMaps related changes. These are also fine, but please > make clearAllValueMaps be a static function in the Constant class, > Constant::ClearAllValueMaps(). > 4. The Types change, including the vector. As you guessed, I'm not a fan > of this at all: it adds overhead to the nor...

...ey are public member variables of the ConstantBool class... If } >>only everyone used the ConstantBool::get() there would be no problem, } >>but that's not the case. Any suggestions? } > } >These should just be destroyed along with the rest of the constants, by } >Constant::clearAllValueMaps. } } Hmmm, I was planning to call clearAllValueMaps once in a while to clear } out the float constants which are building up on me... This shouldn't } break anything as it stands, since the constants will be regenerated. } However, deleting True and False will cause big problems. I think I...

...ssor functions > since they are public member variables of the ConstantBool class... If > only everyone used the ConstantBool::get() there would be no problem, > but that's not the case. Any suggestions? These should just be destroyed along with the rest of the constants, by Constant::clearAllValueMaps. -Chris -- http://llvm.org/ http://nondot.org/sabre/

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm getting,

Chris Lattner wrote: >>It would also solve another problem -- We generate new shader code when >>the user changes parameters, because the shader will be executed >>millions of times it makes sense to recompile it with changed constants >>to get maximum optimization. But if some of these parameters are floats, >>and there is no way to destroy constants in LLVM we have

On Thu, 11 Nov 2004, Morten Ofstad wrote: > Well, I already tried that, but the destructors crash because they are > referencing other things which are being destroyed - Constants are Users > of each other and there is no easy way to destroy them in the right > order. There are ways around this, but it turns into a two-pass operation: loop over all constants to drop their uses, then

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.