similar to: [LLVMdev] Update load/store alignments

On 12/13/13 4:00 AM, Mario Schwalbe wrote: > Hi all, > > although I feel like this is a too simple question, I can't find the answer > right now. > > I have a pass that changes the alignment constraints of global variables > of a module, which doesn't affect any loads and stores of them. So how > do I get the loads' and stores' alignment constraints also

Hi all, I am newbie for llvm. I just create a global variable, there are some statements in my pass like: LoadInst* int64_64 = new LoadInst(pthreadPID, "", false, OptAplusOne); int64_64->setAlignment(8); int64_64->dump(); LoadInst* int32_65 = new LoadInst(gvar_int32_myFlag, "", false, OptAplusOne); int32_65->setAlignment(4);

Hi, guys. I'm a newbie to LLVM and have a very simple question. Which instructions should I use (in terms of IRBuilder calls) to allocate an array of bytes in stack (alloca?), then to work with it (from a given offset) as with integer (bitcast?). I mean something like that: unsigned char var[8]; unsigned int offset = 3; int val = *(int*)(&var+offset); /* read */ *(int*)(&var+offset)

Hi Everyone, I'm quite new to LLVM and I want to update value of global variable in LLVM IR. I created new global variable in ModulePass: bool runOnModule(llvm::Module &M) { IRBuilder<> Builder(M.getContext()); Instruction *I = &*inst_begin(M.getFunction("main")); Builder.SetInsertPoint(I); M.getOrInsertGlobal("globalKey",

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

I don't think it's the same problem as you described. By printing I meant calling printf function and passing my global variable as one of the arguments. My code: Instruction* InstructionVisitor::incrementGlobalKey(Instruction* I) { IRBuilder<> Builder(I->getContext()); Builder.SetInsertPoint(I->getNextNode()); GlobalVariable* key =

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined. I think it's time to

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start

What LoopVectorize.cpp has are the following. Each function may have to have a separate consolidation discussion. I'm bringing up getpointerOperand() since I actually found multiple instances defined/used. DependenceAnalysis.cpp has isLoadOrStore(). LoopAccessAnalysis.cpp has getAddressSpaceOperand(). I'm sure there are others that might be worth discussing within this thread or a follow

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > Hi all, > > This patch is to fix a problem on PPC64 where an unaligned memcpy is > generated. The testcase is this: > > $ cat testcase.c > void Qux() { > char Bar[11] = {0}; > } > > What happens is that we produce LLVM code like this: > > call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11

It's not reproducible with 'opt'. I call the SLP pass from my application and only then the wrong IR gets generated. On the attached module I call via the function pass manager: 1) TargetLibraryInfo with the target triple 2) Set the data layout 3) Basic Alias Analysis 4) SLP vectorizer This produces the wrong IR. On the other hand running the attached module through 'opt

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

Hi all, This patch is to fix a problem on PPC64 where an unaligned memcpy is generated. The testcase is this: $ cat testcase.c void Qux() { char Bar[11] = {0}; } What happens is that we produce LLVM code like this: call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11 x i8]* @C.103.30698, i32 0, i32 0), i64 11, i32 8 ) Notice that it has an 8-byte alignment. However, the Bar

> On Aug 7, 2014, at 2:57 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > > Your .ll file does not have a data layout. Opt will not initialize the DataLayoutPass. The SLP vectorizer will not vectorize because there is no DataLayoutPass. > > debug-cmake/bin/opt -default-data-layout="e-m:e-i64:64-f80:128-n8:16:32:64-S128" -basicaa -slp-vectorizer -S

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not