search for: constantbool

Chris Lattner wrote: >>The four leaks are caused by the ConstantBool::True >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - >> unfortunately they are not so easy to wrap with accessor functions >>since they are public member variables of the ConstantBool class... If >>only everyone used the ConstantBool::get() there...

...attached to this message. That got rid of all but 4 leaks I'm getting, but of course there are more of the same waiting to happen - the pattern of creating singletons with new instead of having static objects inside accessor functions is very common in LLVM. The four leaks are caused by the ConstantBool::True and ConstantBool::False (1 for each object + 1 for the use list dummy) - unfortunately they are not so easy to wrap with accessor functions since they are public member variables of the ConstantBool class... If only everyone used the ConstantBool::get() there would be no problem, but t...

Is there are reason why ConstantInt::getRawValue method can't be moved one step into class hierarchy, into ConstantIntegral::getRawValue The reason I'd like this is that to handle both ConstantInt and ConstantBool, I need the following: if (ConstantInt* CI = dyn_cast<ConstantInt>(V)) { BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getRawValue()); } if (ConstantBool* CB = dyn_cast<ConstantBool>(V)) { BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getalue()); } ... If...

...ing singletons > with new instead of having static objects inside accessor functions is > very common in LLVM. Yes it is. I'm still mostly of the opinion that memory live at exit shouldn't have to be free'd, but I can appreciate tidiness :) > The four leaks are caused by the ConstantBool::True > and ConstantBool::False (1 for each object + 1 for the use list dummy) - > unfortunately they are not so easy to wrap with accessor functions > since they are public member variables of the ConstantBool class... If > only everyone used the ConstantBool::get() there would be no...

Morten Ofstad wrote: } Chris Lattner wrote: } >>The four leaks are caused by the ConstantBool::True } >>and ConstantBool::False (1 for each object + 1 for the use list dummy) - } >> unfortunately they are not so easy to wrap with accessor functions } >>since they are public member variables of the ConstantBool class... If } >>only everyone used the ConstantBool::get(...

On Thu, 17 Jun 2004, Vladimir Prus wrote: > Is there are reason why ConstantInt::getRawValue method can't be moved one > step into class hierarchy, into ConstantIntegral::getRawValue > > The reason I'd like this is that to handle both ConstantInt and ConstantBool, > I need the following: > > if (ConstantInt* CI = dyn_cast<ConstantInt>(V)) { > BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getRawValue()); > } if (ConstantBool* CB = dyn_cast<ConstantBool>(V)) { > BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI-&...

...tantInt>(V)) { > > BuildMI(*MBB, IPt, NM::MOVE, 1, Reg).addImm(CI->getRawValue()); > > } ... > > > > which is a bit nicer. Of course, if you think it's a good idea, I can > > send a patch. > > Sure that sounds great. It increases the size of the ConstantBool class, > but since there are only two instances of it ever created, I think we can > live with this. :) I actually meant making getRawValue into a virtual function, so the size of ConstantBool won't change, but speed might change. I'm not at all sure that the virtual call overhead...

...lass. *. Reid split the 'div' instruction into fdiv/sdiv/udiv operations and 'rem' into frem/srem/urem. We hope that LLVM 2.0 will split all instructions that vary behavior based on the signedness of their operands. See http://llvm.org/PR950 for more details. *. ConstantBool::True and False have been renamed to ConstantBool::getTrue() and ConstantBool::getFalse(). LLVM Build System Changes: *. The LLVM library dependency graph is now acyclic, allowing llvm-config to always work. The LLVM build system itself now internally uses llvm-config. *. Rei...

...not happen, but I don't understand the rationale for this. // FIXME: When we support 'external weak' references, we have to prevent // this transformation from happening. In the meantime we avoid folding // any cast of an external symbol. if (!GV->isExternal()) return ConstantBool::True; This particular transformation is quite important for me because I have some symbols which are either ConstantPointerNull or a GlovalVariable depending on which context the program is compiled in. This is used to implement a kind of conditional compilation, and I'm relying on the co...

...class. 35. Reid split the 'div' instruction into fdiv/sdiv/udiv operations and 'rem' into frem/srem/urem. We hope that LLVM 2.0 will split all instructions that vary behavior based on the signedness of their operands. See http://llvm.org/PR950 for more details. 36. ConstantBool::True and False have been renamed to ConstantBool::getTrue() and ConstantBool::getFalse(). LLVM Build System Changes: 37. The LLVM library dependency graph is now acyclic, allowing llvm-config to always work. The LLVM build system itself now internally uses llvm-config. 38. Reid...

...oning.h's CloneFunctionInto() needs a DenseMap as its third argument instead of an STL map. * Pass's constructor now needs an intptr_t as explained in the updated "Write your first pass"-document. * In my own code, I can't use cout anymore without the std:: prefix. * ConstantBool/Integral/Int are merged into ConstantInt. * %llvm.dbg.subprogram.type's line number is now the 7th element; its compile unit is now the 6th element. * Argument names have got their argument index appended to their name in the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 % Oth...

...nctionInto() needs a > DenseMap as its third argument instead of an STL map. > * Pass's constructor now needs an intptr_t as explained in the updated > "Write your first pass"-document. > * In my own code, I can't use cout anymore without the std:: prefix. > * ConstantBool/Integral/Int are merged into ConstantInt. > * %llvm.dbg.subprogram.type's line number is now the 7th element; > its compile unit is now the 6th element. > * Argument names have got their argument index appended to their name in the > LLVM bitcode (e.g. "define void @f(i32 %...

...an ARM subtarget). 31. The PowerPC 64 JIT now supports addressing code loaded above the 2G boundary. 32. Nick Lewycky contributed several patches to improve support for the Linux/ppc ABI. 33. Jim contributed many bug fixes for PowerPC 64. Internal Cleanups: 34. Sheng merged the ConstantBool, ConstantIntegral and ConstantInt classes together, we now just have ConstantInt. 35. LLVM no longer relies on static destructors to shut itself down. Instead, it lazily initializes itself and shuts down when llvm_shutdown() is explicitly called. 36. LLVM now has significantly few...