search for: mayreadorwritememory

...-calculate an estimate as to the map size we need. For example, in EarlyCSE, this is possibly gross overestimate of size needed: unsigned InstCount = 0; unsigned LoadCount = 0; unsigned CallCount = 0; for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) { if (FI->mayReadOrWriteMemory()) ++LoadCount; else if (isa<CallInst>(*FI)) ++CallCount; else ++InstCount; } AvailableValues.resize(InstCount); AvailableLoads.resize(LoadCount); AvailableCalls.resize(CallCount); But it does the job, and saves ~20% of time in EarlyCSE on my profiles. Yes,...

...arallel loop metadata simplification > > On 03/05/2013 07:12 PM, Redmond, Paul wrote: > > Attached is my most recent patch for clang. Maybe someone wants to > > play with > > it or has ideas on how to refine the llvm.mem metadata generation. > > + } else if (I->mayReadOrWriteMemory()) > + I->setMetadata("llvm.mem.parallel_loop_access", > + L.GetLoopID(I->getContext())); > + } > > Here we want to not add metadata to load/store > instructions which originate from unsafe allocas > like discussed. > > I wonder...

On 03/05/2013 07:12 PM, Redmond, Paul wrote: > Attached is my most recent patch for clang. Maybe someone wants to play with > it or has ideas on how to refine the llvm.mem metadata generation. + } else if (I->mayReadOrWriteMemory()) + I->setMetadata("llvm.mem.parallel_loop_access", + L.GetLoopID(I->getContext())); + } Here we want to not add metadata to load/store instructions which originate from unsafe allocas like discussed. I wonder if there's an easier way to find this ou...

Hi, On 2013-03-03, at 2:58 PM, Hal Finkel wrote: > > I agree; we should only annotate accesses that some from language-level array/pointer(/reference) accesses. We should then rely on other passes to clean up (or not) the remainder. > > I think that the best way to handle local arrays is to issue a warning when they occur inside an annotated loop that the local array will probably

...at instructions in the same loop require different metadatas (one is parallel in both inner and outer loop and another is only parallel in the inner loop?) This is a more general problem I think but the IRBuilder would only be useful for brute force adding the same metadata to all instructions with mayReadOrWriteMemory(). Thoughts? paul > > -Hal > >> >> I'd like to reopen the discussion on requiring the >> llvm.mem.parallel_loop_access metadata. I understand the reason for >> the metadata is to protect against transformations that may >> introduce unsafe parallel m...

...uire different metadatas (one is parallel in both inner and >> outer loop and another is only parallel in the inner loop?) This is >> a more general problem I think but the IRBuilder would only be >> useful for brute force adding the same metadata to all instructions >> with mayReadOrWriteMemory(). > > Well, it would be more complicated than that anyway because you specifically don't want to tag the loads and stores to the local alloca'd variable storage locations, only the "explicit" memory references. I think an extra boolean parameter to CreateLoad, etc. could t...

...me > loop require different metadatas (one is parallel in both inner and > outer loop and another is only parallel in the inner loop?) This is > a more general problem I think but the IRBuilder would only be > useful for brute force adding the same metadata to all instructions > with mayReadOrWriteMemory(). Well, it would be more complicated than that anyway because you specifically don't want to tag the loads and stores to the local alloca'd variable storage locations, only the "explicit" memory references. I think an extra boolean parameter to CreateLoad, etc. could take care o...

...example, in EarlyCSE, this is possibly gross overestimate of size needed: >> >> unsigned InstCount = 0; >> unsigned LoadCount = 0; >> unsigned CallCount = 0; >> for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) { >> if (FI->mayReadOrWriteMemory()) >> ++LoadCount; >> else if (isa<CallInst>(*FI)) >> ++CallCount; >> else >> ++InstCount; >> } >> AvailableValues.resize(InstCount); >> AvailableLoads.resize(LoadCount); >> AvailableCalls.resize(CallCount...

...he map size we need. For example, in EarlyCSE, this is possibly gross overestimate of size needed: > > unsigned InstCount = 0; > unsigned LoadCount = 0; > unsigned CallCount = 0; > for (inst_iterator FI = inst_begin(F), FE = inst_end(F); FI != FE; ++FI) { > if (FI->mayReadOrWriteMemory()) > ++LoadCount; > else if (isa<CallInst>(*FI)) > ++CallCount; > else > ++InstCount; > } > AvailableValues.resize(InstCount); > AvailableLoads.resize(LoadCount); > AvailableCalls.resize(CallCount); > > But it does the job, a...

...gt;> and > >> outer loop and another is only parallel in the inner loop?) This > >> is > >> a more general problem I think but the IRBuilder would only be > >> useful for brute force adding the same metadata to all > >> instructions > >> with mayReadOrWriteMemory(). > > > > Well, it would be more complicated than that anyway because you > > specifically don't want to tag the loads and stores to the local > > alloca'd variable storage locations, only the "explicit" memory > > references. I think an extra boole...

...outer loop and another is only parallel in the inner loop?) This > > >> is > > >> a more general problem I think but the IRBuilder would only be > > >> useful for brute force adding the same metadata to all > > >> instructions > > >> with mayReadOrWriteMemory(). > > > > > > Well, it would be more complicated than that anyway because you > > > specifically don't want to tag the loads and stores to the local > > > alloca'd variable storage locations, only the "explicit" memory > > > reference...

On 01/27/2016 07:53 AM, Daniel Berlin wrote: > > > On Wed, Jan 27, 2016 at 1:27 AM, Roman Gareev <gareevroman at gmail.com > <mailto:gareevroman at gmail.com>> wrote: > > Thank you for the idea! Could you please explain it? > > > Which part are you having trouble with, so i know where to concetrate? > > If I’m not > mistaken, you advise

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Thursday, February 28, 2013 1:30:57 PM > Subject: [LLVMdev] parallel loop metadata simplification > > Hi, > > I've been working on clang codegen for #pragma ivdep and creating the >

...p and another is only parallel in the inner loop?) This >>>>> is >>>>> a more general problem I think but the IRBuilder would only be >>>>> useful for brute force adding the same metadata to all >>>>> instructions >>>>> with mayReadOrWriteMemory(). >>>> >>>> Well, it would be more complicated than that anyway because you >>>> specifically don't want to tag the loads and stores to the local >>>> alloca'd variable storage locations, only the "explicit" memory >>>>...

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable