similar to: [LLVMdev] assert in InnerLoopVectorizer::createEmptyLoop

I am seeing an assert when I compile the attached program with clang: $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm It asserts when LoopVectorize.cpp:506 is executed. It looks like it is complaining because it is trying to zero-extend an i64 (type Count->getType() returns i64) to an i32 (IdxTy). if (Count->getType()

Please file a bug for these types of issues. On Fri, Dec 21, 2012 at 1:49 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I am seeing an assert when I compile the attached program with clang: > > $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 > -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm > > > It asserts when LoopVectorize.cpp:506 is

I need to create a cast instruction that casts an sbyte* to another pointer type. Previously I was using the CastInst::createInferredCast() function to do that; however, that function has been removed. Which of the create() functions from CastInst should I use to do that? It seems like the obdvious answer should be createPointerCast(). However, the documentation for createPointerCast

Hi All, My instrumentation code needs to insert calls to transmit Value list. Each element in this list could be of different type. The list is sent to instrumenting function say void recordVarInputValues(int num, ...) . So, I have created a Union type in Tracing.cpp, which I link with my benchmark module at compile time. These steps are similar to giri instrumentation

On 10/6/11 12:40 PM, Rafael Baldiati Parizi wrote: > virtual std::vector<Value *> getESetArgumentosFunc(Function *F){ > std::vector<Value *> varg_list; > varg_list.clear(); > for(Function::arg_iterator arg_iti = F->getArgumentList().begin(), > arg_ite = F->getArgumentList().end(); arg_iti != arg_ite; ++arg_iti){ > Value *para = >

Hi Sarath, It would have really helped if you had removed the commented out code and inlined the calls to your homemade helper functions before sending it... You are doing this, in LLVM IR: %0 = getelementptr %Value* %firstArg, i32 0 ; i8** %1 = load i8** %0 ; i8* %2 = bitcast i8* %1 to i64* %3 = getelementptr %Value* %secondArg, i32 0 ; i8** %4 = load i8** %3; i8* %5 = bitcast i8* %4 to i64*

Hello. Mikhail, with the more recent version of the LoopVectorize.cpp code (retrieved at the beginning of July 2016) I ran the following piece of C code: void foo(long *A, long *B, long *C, long N) { for (long i = 0; i < N; ++i) { C[i] = A[i] + B[i]; } } The vectorized LLVM program I obtain contains 2 vector.body blocks - one named

Yeah, that's the fault...got the answer...... Thanks James for the help... Struggling with this for so many days....... On Thu, Sep 22, 2011 at 4:02 PM, James Molloy <James.Molloy at arm.com> wrote: > Hi Sarath,**** > > ** ** > > It would have really helped if you had removed the commented out code and > inlined the calls to your homemade helper functions before

On Thu, Sep 22, 2011 at 3:46 PM, sarath chandra <sarathcse19 at gmail.com>wrote: > Hi James, > > First i converted the void * to int* and then did FPToSI...then did SHL...( > because CreateShl only accepts integers... i pointer casted it to int64 type > first)... Below is the code snippet.... > > > lhs = mBuilder.CreateStructGEP(firstArg, 0); > lhs =

On 03/14/2017 12:11 PM, Adam Nemet wrote: > >> On Mar 14, 2017, at 9:49 AM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 03/14/2017 11:21 AM, Adam Nemet wrote: >>> >>>> On Mar 14, 2017, at 6:00 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com >>>> <mailto:Ashutosh.Nema at

Summarizing the discussion on the implementation approaches. Discussed about two approaches, first running ‘InnerLoopVectorizer’ again on the epilog loop immediately after vectorizing the original loop within the same vectorization pass, the second approach where re-running vectorization pass and limiting vectorization factor of epilog loop by metadata. <Approach-2> Challenges with

On 03/14/2017 11:21 AM, Adam Nemet wrote: > >> On Mar 14, 2017, at 6:00 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com >> <mailto:Ashutosh.Nema at amd.com>> wrote: >> >> Summarizing the discussion on the implementation approaches. >> Discussed about two approaches, first running ‘InnerLoopVectorizer’ >> again on the epilog loop immediately after

On 03/14/2017 11:58 AM, Michael Kuperstein wrote: > I'm still not sure about this, for a few reasons: > > 1) I'd like to try to treat epilogue loops the same way regardless of > whether the main loop was vectorized by hand or automatically. So if > someone hand-wrote an avx-512 16-wide loop, with alias checks, and we > decide it's profitable to vectorize the

Hi folk, I get the following stack trace and do have any clue how to fix the problem. 0 opt 0x087ecc99 1 opt 0x087ed265 2 0xb7f6a400 __kernel_sigreturn + 0 3 opt 0x086d4198 llvm::LeakDetector::addGarbageObject(llvm::Value const*) + 29 4 opt 0x0872945f llvm::Instruction::Instruction(llvm::Type const*, unsigned int,

Hi all: I am trying to get the return value of a call instruction that I inserted during the optimization pass I wrote. I have something like the following: CallInst *InitCall = CallInst::Create(InitFn, Args.begin(), Args.end(), "log_load_addr_ret", LI); CastInst *InsertedCast =

Hi Alex, I think the changes you want are actually not vectorizer related. Vectorizer just uses data provided by other passes. What you probably might want is to look into routine Loop::getStartLoc() (see lib/Analysis/LoopInfo.cpp). If you find a way to improve it, patches are welcome:) Thanks, Michael > On Jun 3, 2016, at 6:13 PM, Alex Susu <alex.e.susu at gmail.com> wrote: >

On 03/14/2017 07:50 PM, Adam Nemet wrote: > >> On Mar 14, 2017, at 11:33 AM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> >> On 03/14/2017 12:11 PM, Adam Nemet wrote: >>> >>>> On Mar 14, 2017, at 9:49 AM, Hal Finkel <hfinkel at anl.gov >>>> <mailto:hfinkel at

On 03/14/2017 02:37 PM, Michael Kuperstein wrote: > > > On Tue, Mar 14, 2017 at 11:40 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > > On 03/14/2017 11:58 AM, Michael Kuperstein wrote: >> I'm still not sure about this, for a few reasons: >> >> 1) I'd like to try to treat epilogue loops the

On Mon, Jan 5, 2015 at 1:40 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this situation. It fires when > the function types on both sides of the bitcast have the same number of > operands and compatible types. It then adds bitcasts on the arguments and > removes the one on the called function. > It

Did you update llvm and build that first? -Tanya On May 21, 2008, at 10:29 PM, Rajika Kumarasiri wrote: > hi all, > I was trying to build the latest LLVM gcc front end and it failed. > > rajika@:~/project/llvm/dst-directory$ svn info | grep URL > URL: http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk > > configure option: ../dst-directory/configure --prefix=/usr/local/