search for: llvmfoldingbuilder

Hello llvm dev peeps I would like to use an LLVMBuilder pointer as a base pointer to reference either an LLVMBuilder or an LLVMFoldingBuilder. As the methods in the Folding builder have the same names as the base class, I thought about submitting a patch whereby the base class methods would become virtual. However, the base class methods return specific types while the Folding builder, for good reason, return more general Value* type...

Hi, > Another option that was discussed in #llvm is to nuke LLVMBuilder and > rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd > argue for a flag in the Builder that could retain the old non-folding > functionality for debugging purposes. this plan sounds good to me. However it's not clear to me how useful a debug flag would really be. Ciao, Duncan.

On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote: > Hello llvm dev peeps > > I would like to use an LLVMBuilder pointer as a base pointer to > reference either an LLVMBuilder or an LLVMFoldingBuilder. As the > methods > in the Folding builder have the same names as the base class, I > thought > about submitting a patch whereby the base class methods would become > virtual. However, the base class methods return specific types while > the > Folding builder, for good re...

Duncan Sands wrote: >> Another option that was discussed in #llvm is to nuke LLVMBuilder and >> rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd >> argue for a flag in the Builder that could retain the old non-folding >> functionality for debugging purposes. >> > > this plan sounds good to me. However it's not clear to me how useful a > debug flag would rea...

Hi, the functionality of LLVMFoldingBuilder has been folded into LLVMBuilder, which has been renamed to IRBuilder. If you were using LLVMFoldingBuilder then it should be enough to rename LLVMFoldingBuilder to IRBuilder everywhere (and change the #include from LLVMBuilder to IRBuilder). If you were using LLVMBuilder then as well as renaming...

Dominic Hamon wrote: > Duncan Sands wrote: >>> Another option that was discussed in #llvm is to nuke LLVMBuilder >>> and rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, >>> I'd argue for a flag in the Builder that could retain the old >>> non-folding functionality for debugging purposes. >>> >> >> this plan sounds good to me. However it's not clear to me how useful a >&...

On Apr 10, 2008, at 7:05 AM, Dominic Hamon wrote: > Dominic Hamon wrote: >> Duncan Sands wrote: >>>> Another option that was discussed in #llvm is to nuke LLVMBuilder >>>> and rename LLVMFoldingBuilder to LLVMBuilder. If this was the >>>> case, I'd argue for a flag in the Builder that could retain the >>>> old non-folding functionality for debugging purposes. >>>> >>> >>> this plan sounds good to me. However it's not clear to me h...

Am Donnerstag, den 03.04.2008, 19:29 -0700 schrieb Chris Lattner: > On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote: > > > Would it be reasonable for me to submit a patch whereby [...] the > > LLVMFoldingBuilder methods become virtual overrides of the base > > class methods? > > No, please don't do this. The idea of llvmbuilder is that it is a > "free" wrapper around the other existing API calls. Making the > methods virtual would make them much more expensive. Would...

...version of printf(). (It seemed like a good choice because it touches many data types, varargs, etc.) I've had to make quite a few changes to Elsa to get this going, but so far I haven't had to touch LLVM. I got the current version of LLVM via svn yesterday and modified my code to use the LLVMFoldingBuilder. Very nice! My question is this: I noticed that the folding builder doesn't fold some operations, e.g. casts. Is there some reason why? If I implemented some of these unhandled cases could I sumbit the changes back to the LLVM project? -Rich

On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > I got the current version of LLVM via svn yesterday and modified my > code to > use the LLVMFoldingBuilder. Very nice! > > My question is this: I noticed that the folding builder doesn't fold > some > operations, e.g. casts. Is there some reason why? If I implemented > some of > these unhandled cases could I sumbit the changes back to the LLVM > project? Sure. Though, I d...

On Fri, 4 Apr 2008, Joachim Durchholz wrote: >> No, please don't do this. The idea of llvmbuilder is that it is a >> "free" wrapper around the other existing API calls. Making the >> methods virtual would make them much more expensive. > > Wouldn't the class of the objects be known at compile time in most > cases? This is essentially just a case of

On Fri, 4 Apr 2008, Joachim Durchholz wrote: >> Please verify that this actually happens in practice with llvm-gcc and >> gcc. > > If that's already the case (which I'll gladly believe), where does the > performance overhead for virtual functions come from? > (Just curious.) I don't understand what you're asking. Please rephrase. -Chris --

On Apr 4, 2008, at 3:59 PM, Joachim Durchholz wrote: > > I'm not sure how hard (a) really is. It's being done in other > imperative > OO languages, and quite successful there (the SmartEiffel folks have > reported they can eliminate the vtable lookup in about 90% of call > sites, Are those the folks that don't do separate compilation or dynamic libraries? :-)

On Apr 11, 2008, at 02:19, Chris Lattner wrote: > On Apr 10, 2008, at 7:05 AM, Dominic Hamon wrote: > >> And there were. updated patches attached. > > Looking good. One big comment: Please attach patches to email > instead of including them inline. Thunderbird and Mail are once again conspiring against Chris. The fix is to make Thunderbird attach attachments instead of

> Please find _attached_ the update patches with all requested changes. Applied - thanks! Ciao, Duncan.

On Apr 12, 2008, at 11:28 PM, Duncan Sands wrote: >> Please find _attached_ the update patches with all requested changes. > > Applied - thanks! > In the future, can all major API changes please be checked in after giving some warning to the community? For example, send a separate email title "API Change" and then give some sort of warning as to when it will go in

...; + } This should constant fold if Ptr is a constant. + CallInst *CreateCall(Value *Callee, const char *Name = "") { + return Insert(CallInst::Create(Callee, Name)); You should be indenting by two spaces (I think Chris mentioned this). - DEFINE_SIMPLE_CONVERSION_FUNCTIONS(LLVMFoldingBuilder, LLVMBuilderRef ) + DEFINE_SIMPLE_CONVERSION_FUNCTIONS(IRBuilder, LLVMBuilderRef ) DEFINE_SIMPLE_CONVERSION_FUNCTIONS(PATypeHolder, LLVMTypeHandleRef ) Please add spaces so that these line up again. -<p>Well, that was easy :). In practice, we recommend always using...

Am Freitag, den 04.04.2008, 15:19 -0400 schrieb Jonathan S. Shapiro: > In general, the C++ compiler does NOT know the type of the leaf class > when performing a virtual method invocation. In particular, a parameter > (including "this") alleging to be a Foo* (Foo being some class) may > actually be any subclass of Foo, so unless the compiler can trace the > value flow all

Duncan Sands wrote: > + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, > + const char *Name = "") { > + llvm::Value *Idxs[] = { > + ConstantInt::get(llvm::Type::Int32Ty, 0), > + ConstantInt::get(llvm::Type::Int32Ty, Idx) > + }; > + return Insert(GetElementPtrInst::Create(Ptr, Idxs, Idxs+2, Name));

Hola LLVMers, We saw a problem with some code in LiveIntervalAnalysis.h/.c which we've fixed locally. We'd like to get a patch to the mainline and want to know how you'd like it fixed. A couple of things come together to cause the problem: struct Idx2MBBCompare { bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) const { return LHS.first <