search for: memcpyoptimizer

...ave a memset at IR level. > > > Same for store to 24(%rsp), which is later overwritten at lines 11 and 16. > > I’m not sure what we should do here… If it were a constant store we’d fold it in, but here both stores are variables so it’s not clear that we really should be doing much in MemCpyOptimizer. > The problem I see here is: there’s a small memset, followed by variable stores to the same location. DCE’ing requires realizing that the memset is small enough that the backend will expand it, at which point DCE will kick in. MemCpyOptimizer doesn’t know what “small” is, partly because it’s b...

...for store to 24(%rsp), which is later overwritten at lines 11 >> and 16. >> > >> > I’m not sure what we should do here… If it were a constant store we’d >> fold it in, but here both stores are variables so it’s not clear that we >> really should be doing much in MemCpyOptimizer. >> > The problem I see here is: there’s a small memset, followed by variable >> stores to the same location. DCE’ing requires realizing that the memset is >> small enough that the backend will expand it, at which point DCE will kick >> in. MemCpyOptimizer doesn’t know wh...

On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > > Hi Alexander, > > The code doesn’t compile. Could you send a godbolt.org link that shows the issue? Sorry about that, here's the link: https://godbolt.org/z/-PinQP Lines 4 to 8 are initializing |acpar|. If I'm understanding correctly, the store to 8(%rsp) at line 7 can be removed because of the

...ransforms $ grep -Rl MustAlias . > >> ./ObjCARC/ObjCARCOpts.cpp > >> ./ObjCARC/ProvenanceAnalysis.cpp > >> ./Scalar/DeadStoreElimination.cpp > >> ./Scalar/GVN.cpp > >> ./Scalar/LICM.cpp > >> ./Scalar/LoopVersioningLICM.cpp > >> ./Scalar/MemCpyOptimizer.cpp > >> ./Scalar/MergedLoadStoreMotion.cpp > >> ./Scalar/NewGVN.cpp > >> ./Utils/VNCoercion.cpp > >> > >> I glanced over all the uses in these files and I couldn't find any > >> usage that requires sizes to match. Actually most clients che...

...of MustAlias: >> ~/llvm/lib/Transforms $ grep -Rl MustAlias . >> ./ObjCARC/ObjCARCOpts.cpp >> ./ObjCARC/ProvenanceAnalysis.cpp >> ./Scalar/DeadStoreElimination.cpp >> ./Scalar/GVN.cpp >> ./Scalar/LICM.cpp >> ./Scalar/LoopVersioningLICM.cpp >> ./Scalar/MemCpyOptimizer.cpp >> ./Scalar/MergedLoadStoreMotion.cpp >> ./Scalar/NewGVN.cpp >> ./Utils/VNCoercion.cpp >> >> I glanced over all the uses in these files and I couldn't find any usage >> that requires sizes to match. Actually most clients check access sizes >> thems...

...A.Size == LocB.Size ? MustAlias : PartialAlias; I grepped for clients of MustAlias: ~/llvm/lib/Transforms $ grep -Rl MustAlias . ./ObjCARC/ObjCARCOpts.cpp ./ObjCARC/ProvenanceAnalysis.cpp ./Scalar/DeadStoreElimination.cpp ./Scalar/GVN.cpp ./Scalar/LICM.cpp ./Scalar/LoopVersioningLICM.cpp ./Scalar/MemCpyOptimizer.cpp ./Scalar/MergedLoadStoreMotion.cpp ./Scalar/NewGVN.cpp ./Utils/VNCoercion.cpp I glanced over all the uses in these files and I couldn't find any usage that requires sizes to match. Actually most clients check access sizes themselves. Most don't need equal sizes, just need one to be...

Hello all, I'm trying to find the pass that would convert from: define void @main(%struct* byval %ptr) { %val = load %struct* %ptr %val.ptr = alloca %struct store %struct %val, %struct* %val.ptr call void @extern_func(%struct* byval %val.ptr) ret void } to this: define void @main(%struct* byval %ptr) { call void @extern_func(%struct* byval %ptr) ret void } First, am I missing

...ieces. If that happens, you're example should come "for free" provided that the same example works when you break down the FCA into it's component pieces. If it doesn't, please say so. Philip On 03/05/2015 04:21 PM, Reid Kleckner wrote: > I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the right > place for this, considering that most frontends will use memcpy for > that copy anyway. It already has some logic for byval args. > > On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com > <mailto:mtrofin at google.com>> wrote:...

...> ./ObjCARC/ObjCARCOpts.cpp >>>>> ./ObjCARC/ProvenanceAnalysis.cpp >>>>> ./Scalar/DeadStoreElimination.cpp >>>>> ./Scalar/GVN.cpp >>>>> ./Scalar/LICM.cpp >>>>> ./Scalar/LoopVersioningLICM.cpp >>>>> ./Scalar/MemCpyOptimizer.cpp >>>>> ./Scalar/MergedLoadStoreMotion.cpp >>>>> ./Scalar/NewGVN.cpp >>>>> ./Utils/VNCoercion.cpp >>>>> >>>>> I glanced over all the uses in these files and I couldn't find any >>>>> usage that requires...

..."for free" provided that the same example works when > you break down the FCA into it's component pieces. If it doesn't, > please say so. > > Philip > > > On 03/05/2015 04:21 PM, Reid Kleckner wrote: >> I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the >> right place for this, considering that most frontends will use >> memcpy for that copy anyway. It already has some logic for byval >> args. >> >> On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com >> &l...

...> really not sure which passes you are thinking about here that do code > sinking/speculation that won't need it. > > Here's the list definitely needing it right now: > GVN > GVNHoist > LICM > LoadCombine > LoopReroll > LoopUnswitch > LoopVersioningLICM > MemCpyOptimizer > MergedLoadStoreMotion > Sink > > The list is almost certainly larger than this, this was a pretty trivial > grep and examination. > (and doesn't take into account bugs, etc) > > (Note, this list is stuff in the Scalar directory only. Everything in Vectorize would n ee...

> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> wrote: > > Joining in very late, but the tangent here has been interesting (if rather OT for the original thread). > > I agree with Danny that we might want to take a close look at how we model things like maythrow calls, no return, and other implicit control flow. I'm not convinced that moving

...inking about here that do code >> sinking/speculation that won't need it. >> >> Here's the list definitely needing it right now: >> GVN >> GVNHoist >> LICM >> LoadCombine >> LoopReroll >> LoopUnswitch >> LoopVersioningLICM >> MemCpyOptimizer >> MergedLoadStoreMotion >> Sink >> >> The list is almost certainly larger than this, this was a pretty trivial >> grep and examination. >> (and doesn't take into account bugs, etc) >> >> > > (Note, this list is stuff in the Scalar directory...

Hi Florian, Following up on D86967, I missed that all the timings were using the legacy pass manager. Did you do any testing on the compile and run time impact for the new pass manager? Thank you, Alina On Tue, Aug 25, 2020 at 12:51 PM Florian Hahn <florian_hahn at apple.com> wrote: > Hi, > > Thanks for all the responses! > > My understanding is that there were no

Hello, I'm trying to find if the access within a loop body is using the loop induction variable, and to get the start and end indices of the loop. for(int i = start; i < end; i++) { A[i] = 0; } Let's say, I want to replace this with a function call 'zero(A,start, end)' How can I get the Value for start and end, and see if the index is same as loop induction variable?

Respected Sir, Let me introduce myself,This is Umesh from INDIA who currently working in Hewitt Packard(HP),Where i work in the Virtual Machine(VM) team from past one year in the maintianing the Java Virtual Machine(JVM) on Hp-Ux. I like to contribute to LLVM by utilize my experiences and skills on compilers and virtual machines. Me like to take the bug 715 in bugzilla i.e Fix / clean up

...same example works when you break down the FCA into >>> it's component pieces. If it doesn't, please say so. >>> >>> Philip >>> >>> >>> On 03/05/2015 04:21 PM, Reid Kleckner wrote: >>> >>> I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the right >>> place for this, considering that most frontends will use memcpy for that >>> copy anyway. It already has some logic for byval args. >>> >>> On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com> >>> wrote:...

Hi, LLVM's memory intrinsics are quite useful for performing various optimizations with frequently used memory operations. Unfortunately this intrinsics are not applicable for languages with guaranteed atomicity for their memory accesses (like Java for example). In order to overcome this limitation I'm thinking about adding set of intrinsics which will execute as a series of unordered

> could you allocate the memory on the stack instead (alloca instruction)? This is mainly for string or binary blob handling, using the stack isn't a great idea for size reasons. While I'm experimenting with simple code examples now, and I picked a simple one for this email. I'm certain things will get much more complicated once I implement more features of the language. On Tue,

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For