similar to: [LLVMdev] New LLVMBuilder api

On Sun, 27 May 2007, Aaron Gray wrote: >> I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, > It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or 2.0 > and not cvs ? It is there: http://llvm.org/cvsweb/cvsweb.cgi/llvm/include/llvm/Support/LLVMBuilder.h?rev=HEAD&content-type=text/x-cvsweb-markup -Chris -- http://nondot.org/sabre/

> On Sun, 27 May 2007, Aaron Gray wrote: >>> I just checked in a new LLVMBuilder class into >>> llvm/Support/LLVMBuilder.h, >> It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or >> 2.0 >> and not cvs ? > > It is there: >

> I just checked in a new LLVMBuilder class into llvm/Support/LLVMBuilder.h, It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or 2.0 and not cvs ? Aaron

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

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

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

>> On Sun, 27 May 2007, Aaron Gray wrote: >>>> I just checked in a new LLVMBuilder class into >>>> llvm/Support/LLVMBuilder.h, >>> It does not seem to be on the LLVM cvsweb, is that still showing 1.9 or >>> 2.0 >>> and not cvs ? >> >> It is there: >>

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 >

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

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.

hi, list, I found AMDGPUPromoteAlloca calculates newly ptr as follows: std::tie(TCntY, TCntZ) = getLocalSizeYZ(Builder); Value *TIdX = getWorkitemID(Builder, 0); Value *TIdY = getWorkitemID(Builder, 1); Value *TIdZ = getWorkitemID(Builder, 2); Value *Tmp0 = Builder.CreateMul(TCntY, TCntZ, "", true, true); Tmp0 = Builder.CreateMul(Tmp0, TIdX); Value *Tmp1 =

Hi Dominic, +//===-- llvm/Support/IRBuilder.h - Builder for LLVM Instrs -----*- C++ -*-===// is this line the right length? It seems shorter than the similar lines below like this one: +//===----------------------------------------------------------------------===// + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, + const char *Name =

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 >

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

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));

Am Freitag, den 04.04.2008, 11:19 -0700 schrieb Chris Lattner: > 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

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 LLVMBuilder to IRBuilder you may also need to fix up the

Hi, I observed below behavior with Instruction combiner (visitMul Canonicalization) It tries to convert "(X+C1)*C2" to "X*C2+C1*C2" While transforming if operation is guaranteed to not overflow it does not reflect same property to transformed instructions. Consider following scenarios: 1) If input is ((X+C1)*C2)<nsw> Then post canonicalization output should be

I am trying to compile llvm gcc 4.0 from svn today and I'm getting the error below. It looks like the file LLVMBuilder.h. I looked in past versions of LLVM and that file exists; however, it not longer seams to exist. Has it purposely been removed? ------------------------------------ llvm_optimized/include ../../llvm-gcc-4.0/gcc/llvm-backend.cpp -o llvm-backend.o In file included from

> I am trying to compile llvm gcc 4.0 from svn today and I'm getting the > error below. It looks like the file LLVMBuilder.h. I looked in past > versions of LLVM and that file exists; however, it not longer seams to > exist. Has it purposely been removed? llvm-gcc 4.0 is no longer supported (as of 2.2): http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-February/012416.html To