search for: undebat

...e lists always 'new' one > element, so I could not avoid calling the destructors of the constants > even if they have no (real) uses... 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: 1. Some changes of unsigned to size_t and other things to make VC happy. These are fine. 2. The clearAllValueMaps related changes. These are also fine, but please make clearAllValueMaps be a static function in the Constant class, Constant::ClearAllValueMaps(). 3....

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 no...

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