search for: mayreadorwritememori

Displaying 15 results from an estimated 15 matches for "mayreadorwritememori".

Did you mean: mayreadorwritememory
2016 Mar 15
7
RFC: DenseMap grow() slowness
There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad.
2013 Mar 05
0
[LLVMdev] parallel loop metadata simplification
----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Paul Redmond" <paul.redmond at intel.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "Tobias Grosser" <tobias at grosser.es>, "<llvmdev at cs.uiuc.edu>" > <llvmdev at cs.uiuc.edu> > Sent: Tuesday, March 5,
2013 Mar 05
1
[LLVMdev] parallel 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
2013 Mar 05
2
[LLVMdev] parallel loop metadata simplification
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
2013 Mar 01
2
[LLVMdev] parallel loop metadata simplification
Hi Hal, On 2013-02-28, at 9:33 PM, Hal Finkel wrote: > ----- 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, >>
2013 Mar 01
2
[LLVMdev] parallel loop metadata simplification
On 2013-03-01, at 11:35 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Paul Redmond" <paul.redmond at intel.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> >> Sent: Friday, March 1, 2013 10:06:51 AM >> Subject: Re: [LLVMdev] parallel loop
2013 Mar 01
0
[LLVMdev] parallel loop metadata simplification
----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 1, 2013 10:06:51 AM > Subject: Re: [LLVMdev] parallel loop metadata simplification > > Hi Hal, > > On 2013-02-28, at 9:33
2016 Mar 15
2
RFC: DenseMap grow() slowness
> On Mar 15, 2016, at 4:09 PM, Philip Reames <listmail at philipreames.com> wrote: > > > > On 03/15/2016 03:07 PM, via llvm-dev wrote: >> There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to
2016 Mar 15
2
RFC: DenseMap grow() slowness
What should we use instead of DenseMap? —escha > On Mar 15, 2016, at 3:30 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > yes it makes sense. Avoid using DenseMap when the size of the map is expected to be large but can not be pre-determined. > > David > > On Tue, Mar 15, 2016 at 3:07 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at
2013 Mar 01
0
[LLVMdev] parallel loop metadata simplification
----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 1, 2013 10:49:24 AM > Subject: Re: [LLVMdev] parallel loop metadata simplification > > > On 2013-03-01, at 11:35 AM, Hal
2013 Mar 01
3
[LLVMdev] parallel loop metadata simplification
----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Paul Redmond" <paul.redmond at intel.com> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 1, 2013 11:13:06 AM > Subject: Re: [LLVMdev] parallel loop metadata simplification > > ----- Original Message ----- > >
2016 Jan 27
2
Skip redundant checks in AliasSet::aliasesUnknownInst
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
2013 Mar 01
0
[LLVMdev] parallel loop metadata simplification
----- 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 >
2013 Mar 01
0
[LLVMdev] parallel loop metadata simplification
On 2013-03-01, at 12:23 PM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Hal Finkel" <hfinkel at anl.gov> >> To: "Paul Redmond" <paul.redmond at intel.com> >> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> >> Sent: Friday, March 1, 2013 11:13:06 AM >> Subject: Re: [LLVMdev] parallel loop
2013 Feb 28
5
[LLVMdev] parallel loop metadata simplification
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