search for: mayreadfrommemori

Hi I am currently trying to schedule instructions with my own algorithm. For that i need to get the data dependency between the instructions. So currently i am dooing s.t. like: for(BasicBlock::iterator j=B.begin(),bbe=B.end();j!=bbe;++j) { InstructionList.push_back(j); if (const AllocaInst *AI = dyn_cast<AllocaInst>(j)) {

On Fri, 12 May 2006, Silken Tiger wrote: > To find the first instructions which are not depending on others results. So > far it seems to be working but i am missing instructions like: > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] > There seems only an function like llvm::Instruction::mayWriteToMemory > but nothing like llvm::Instruction::mayReadFromMemory or

Hi Chris and list Thanks for your quick answer :-). Am Freitag, 12. Mai 2006 19:09 schrieb Chris Lattner: > On Fri, 12 May 2006, Silken Tiger wrote: > > To find the first instructions which are not depending on others results. > > So far it seems to be working but i am missing instructions like: > > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] > >

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

Alexandra, I'm not sure what you mean by "replace", but I have code that does this to insert prefetches: Type *I8Ptr = Type::getInt8PtrTy((*I)->getContext(), PtrAddrSpace); Value *PrefPtrValue = ... IRBuilder<> Builder(MemI); Module *M = (*I)->getParent()->getParent(); Type *I32 = Type::getInt32Ty((*I)->getContext()); Value

Hello, Can anyone please guide me how can I replace a load instruction with a prefetch. I was looking at the intrinsic creation methods of the IRBuilder, but I can only find functions corresponding to memset, memcpy and memmove intrinsics, not for prefetching. Also, I target x86-64 architectures. Is it sufficient to insert a call to the intrinsic in the LLVM IR to have the corresponding prefetch

On Mon, Mar 7, 2011 at 8:03 PM, Hari Pyla <harip at vt.edu> wrote: >  Thank you for your response. In my analysis, I will always have > entry(2) and exit(2). I will not run into cases involving entry (1+1) or > entry (fn return values). I am having trouble trying to compare the > arguments of entry and exit in the following scenario. > > #include<stdio.h> >

Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does

Hi Reid, Thank you for your response. In my analysis, I will always have entry(2) and exit(2). I will not run into cases involving entry (1+1) or entry (fn return values). I am having trouble trying to compare the arguments of entry and exit in the following scenario. #include<stdio.h> #include<stdlib.h> #include<pthread.h> struct sa { int a; pthread_mutex_t *mutex1;

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

Hello, I'm working with a pass that operates at the LLVM IR level. I need to run some statistics on instructions that access memory, and I'm wondering, at the IR level, which instructions aside from Load and Store access memory directly as a result of their operation? I know on an ISA level, this varies from arch to arch, but I'm wondering how LLVM has this set up at the IR level.

Howdy, I'm working on writing a dependence analyzer (rather like what LoopDependenceAnalysis wants to be, except a bit more general). While this is a problem of many parts, I'm currently focusing on finding pairs of memory references to test for dependence. Consider this contrived C code: double test2(int n, double *restrict A, double *restrict B, bool flag) { if (flag) { A[0] =

Hi, > On Apr 22, 2016, at 8:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Rob, > > The problem here is that the d[i] array is only conditionally accessed, and so we can't if-convert the loop body. The compiler does not know that d[i] is actually dereferenceable for all i from 0 to 15 (the array might be shorter and p[i] is 0 for i past the end

Hi, A few days ago I stumbled upon a problem where SpeculativeExecution changed the order of a load and a store to the same address. I wrote https://bugs.llvm.org//show_bug.cgi?id=32964 about it but no response there so far. In the input we have store i8 0, i8* @i %.pre = load i8, i8* @i and then in the output the load is moved so it's before the store which clearly makes it

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

Am Mi., 15. Jan. 2020 um 03:30 Uhr schrieb Renato Golin <rengolin at gmail.com>: > > I see it as an advantage in respect of adoption: It can be switched on and off without affecting other parts. > > That's not necessarily true. > > If we do like Polly, it is, but then the ability to reuse code is very > low and the time spent converting across is high. If we want to

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 test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing

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

Am Sa., 11. Jan. 2020 um 07:43 Uhr schrieb Renato Golin <rengolin at gmail.com >: > On Sat, 11 Jan 2020 at 00:34, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Yes, as mentioned in the Q&A. Unfortunately VPlan is able to represent > > arbitrary code not has cheap copies. > > Orthogonal, but we should also be looking into implementing the cheap > copies

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