[llvm-dev] Avoiding during my pass the optimization (copy propagation) of my LLVM IR code (at generation)

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 30 19:20:28 PST 2016


> On Dec 30, 2016, at 3:03 PM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>  Hello.
>    I'm writing an LLVM pass that is working on LLVM IR.
>    To my surprise the following LLVM pass code generates optimized code - it does copy propagation on it.

It does *constant* propagation to be exact.

>      Value *vecShuffleOnePtr = Builder.CreateGEP(ptr_B, vecShuffleOne, "VectorGep");
>      ...
>      packed_gather_params.push_back(vecShuffleOnePtr);
>      CallInst *callGather = Builder.CreateCall(func_llvm_masked_gather_v128i16,
>                                                packed_gather_params);
>      callGather->addAttribute(AttributeSet::FunctionIndex, Attribute::NoUnwind);
> 
>      DEBUG(dbgs() << "callGather: " << *callGather << "\n");
> 
>    When running this code we get at stderr something like:
>        callgather: %50 = call <4 x i16> @llvm.masked.gather.v4i16(<4 x i16*> getelementptr (i16, i16* inttoptr (i16 51 to i16*), <4 x i64> <i64 1, i64 1, i64 1, i64 1>), i32 0, <4 x i1> <i1 true, i1 true, i1 true, i1 true>, <4 x i16> undef)
>    Also, more importantly, the resulting LLVM program will also contain this 1 gather LLVM IR instruction.
> 
>    So, although I instructed LLVM to generate 2 instructions, it creates only one instruction, a call to gather containing as parameter not the VectorGep variable name, but its value/definition, the getelementptr instruction (and this happens even if VectorGep is used more than once in my program).
> 
>    Is there a way to specify programmatically in my LLVM pass to avoid doing this copy propagation optimization (and obtain an LLVM program with a separate getelementptr instruction, besides the gather instruction)?

No: you can’t really force constant to not be propagated (At least I don’t know an easy way for that).

— 
Mehdi





More information about the llvm-dev mailing list