similar to: GVN pass limitation.

Cases like this illustrate why we should avoid arbitrary cutoffs in analysis passes if at all possible. Philip On 04/18/2016 03:08 AM, Joerg Sonnenberger via llvm-dev wrote: > On Mon, Apr 18, 2016 at 05:17:04PM +0800, xiuli pan via llvm-dev wrote: >> So if there is another way to pass this memdep-block-scan-limit into the >> pass manager or context? Or how could I set this

+ llvm-dev From: Sumner, Brian Sent: Tuesday, May 10, 2016 3:11 PM To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; Pan, Xiuli <xiuli.pan at intel.com>; Bader, Alexey (alexey.bader at intel.com) <alexey.bader at intel.com> Cc: Stellard, Thomas

On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > Hi, > > On 01/13/2017 10:29 PM, Daniel Berlin wrote: > >> Yeah, there's a lot of things this could be. >> >> On the memdep side: >> Note that memdep is not actually properly updated in all cases by most >> passes that claim to not invalidate it (they

I would really appreciate it if someone can give suggestions on how to do spectra fitting in R using ordinary least square fitting and non-negativity constraints. The lm() function works well for ordinary least square fitting, but how to specify non-negativity constraints? It wouldn't make sense if the fitting coefficients coming out as negative in absorption spectra deconvolution. Thanks.

Yeah, there's a lot of things this could be. On the memdep side: Note that memdep is not actually properly updated in all cases by most passes that claim to not invalidate it (they don't invalidate dependent pointers, only pointers they directly touch). There's already a bug filed about this. So far we've only seen missed-opt, not wrong code from this. But it should be possible

Chris Lattner schrieb: > > On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > >> Hi, >> >> I do have a FunctionPass that does change the code. This FunctionPass >> requires another FunctionPass which performs all the necessary analyses. >> This AnalysisPass again requires MemoryDependenceAnalysis. >> >> The problem is, that I would like

On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >> This isn't really possible. The issue is that MemDep doesn't just >> "analyze your function". It is designed to be as lazy as possible, >> which means that it only does analysis when a query is performed. >> This >> means that if you have MemDep->Pass1->Pass2 and Pass2 uses MemDep

Chris Lattner schrieb: > On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >>> This isn't really possible. The issue is that MemDep doesn't just >>> "analyze your function". It is designed to be as lazy as possible, >>> which means that it only does analysis when a query is performed. This >>> means that if you have

On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > Hi, > > I do have a FunctionPass that does change the code. This FunctionPass > requires another FunctionPass which performs all the necessary > analyses. > This AnalysisPass again requires MemoryDependenceAnalysis. > > The problem is, that I would like MemoryDependenceAnalysis to run on > the > unaltered

Define soon? My guess is 1 year or less. (I've already seen patches to start converting most remaining memdep uses, like memcpy opt, licm, etc) On Fri, Dec 23, 2016 at 8:27 AM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 17:22 GMT+01:00 Davide Italiano <davide at freebsd.org>: > >> On Fri, Dec 23, 2016 at 8:12 AM, Piotr

2016-12-23 17:22 GMT+01:00 Davide Italiano <davide at freebsd.org>: > On Fri, Dec 23, 2016 at 8:12 AM, Piotr Padlewski via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > > > I started digging into MemDep to enhance devirtualization and I found out > > that it doesn't handle invariant.group if it will find GEP 0, 0. > > If I

Hi, MemDep caches results for local queries and provides means to invalidate them by keeping reverse maps. Unfortunately, it also caches results that represent non-local dependencies, for which there are no reverse map entries, and thus those entries can not be invalidated. This is a problem when an optimization turns a non-local dependency into a local one.

Thanks Daniel, I'll do a debug build of LLVM (I guess that'll teach me) and step through it as soon as I'll find a power outlet. I'm calling getDependency on the load instruction, and it returns the store instruction. Suspiciously enough, calling invalidateCachedPointerInfo on load->getPointerOperand() does not cause my AA pass to be called again when I use getDependency (or

On Fri, Aug 21, 2009 at 10:48 AM, Marc Brünink<marc at bruenink.de> wrote: >>> actually my problem is easier. So I still have hope that it is possible: >>> >>> MemDep->Pass1->Pass2 >>> >>> Pass1 uses MemDep. Pass2 only uses Pass1. Eventually, Pass2 changes the >>> code. Unfortunately, non-local dependencies of MemDep might point to

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

Hello to whom this may concern, Versioned this as I saw identical title before. I'm compiling a clang project where I'm seeing GVN mess up and replace a load with a wrong def value. I am using LLVM-3.5, but the problem has been observed upto 3.8. To illustrate the problem, define i32 @main scalar.ph: <initialize [80 x i16] %dest> ... preheader: %index=0 br test, loop1, bb2

On Dec 23, 2016 19:47, "Daniel Berlin" <dberlin at dberlin.org> wrote: Define soon? My guess is 1 year or less. (I've already seen patches to start converting most remaining memdep uses, like memcpy opt, licm, etc) That's good. Anyway I already have a patch that is doing invariant group dependence across BBs, so I guess it make sense to push it upstream to push the bar

> > > LLVM's design decision is one where everything has to explicitly care > about implicit early exits to get correct answers (and not to harp too > much, but "not everything does", years later). If they don't, they will > get wrong answers. > > So, ironically, while looking at this, i noticed it turns out LLVM's PRE in GVN is another place that

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

On Fri, Dec 23, 2016 at 8:12 AM, Piotr Padlewski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I started digging into MemDep to enhance devirtualization and I found out > that it doesn't handle invariant.group if it will find GEP 0, 0. > If I understand it correctly getelementptr with zeros is just bitcast. Is > there any good reason why it is not