similar to: [LLVMdev] testing a cross compiler

Hi, suppose the following C function declaration: void f(int *in, int *out); Now further suppose, that _in_ is an array only read from and _out_ is an array that is only written to. Based on this, I was wondering whether there is some already existing LLVM pass (or maybe a part of a pass) that detects those "data directions" for pointers. I'm not quite sure whether e.g. Alias

Hi Dmitry, On 01/09/2013 03:48 PM, Dmitry Mikushin wrote: > Hi Sebastian, > > This kind of analysis is a pretty complex problem in general case. > Consider, for instance, function "f" has nested calls of other functions > with "side effects", meaning they could potentially change the contents of > "in" or "out" indirectly. For this

Are you analysing sizes in order to perform host<->accelerator memory synchronization? 2013/1/9 Sebastian Dreßler <dressler at zib.de> > Hi Dmitry, > > On 01/09/2013 03:48 PM, Dmitry Mikushin wrote: > > Hi Sebastian, > > > > This kind of analysis is a pretty complex problem in general case. > > Consider, for instance, function "f" has nested

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

On Wed, Oct 3, 2012 at 10:15 AM, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote: > Preston Briggs <preston.briggs at gmail.com> writes: >> Think about costs asymptotically; that's what matters. Calls and >> returns require constant time, just like addition and multiplication. > > Constant time, but not necessarily constant memory. > > Deep recursion

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.

On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked

Preston, thanks for the explanation and patch. Now it's printing the direction and distance values. On Tue, Nov 13, 2012 at 12:22 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Erkan, you're right. Sorry about that. > Attached is the most recent version. > > Preston > > > > Hi Preston, >> I am trying to use DA as well. I used your example

Yes, I quite liked the things I've read about the PBQP allocator. Given what the hardware folks have to go through to get 1% improvements in scalar code, spending 20% (or whatever) compile time (under control of a flag) seems like nothing. And falling back on "average code" is a little disingenuous. People looking for performance don't care about average code; they care about

I'd like a value, call it Bottom, such that SE->getAddExpr(Bottom, X) => Bottom SE->getMulExpr(Bottom, X,) => Bottom isKnownPredicate(any, Bottom, X) => false etc. I can write code to make NULL work like I want, but it would be simpler if something was already defined. I'm wondering about SCEV::Unknown. The documentation suggests I could perhaps use it for a

My problem was that the constructor for DenseMap has an undocumented constraint. explicit DenseMap(unsigned NumInitBuckets = 0) { init(NumInitBuckets); } if given an explicit argument, requires that the argument be a power of 2. It's checked by an assert in init(), but for some reason my code didn't trip the assertion. Is there a special way I must make to enable asserts? Thanks,

Hi Sebastian, This kind of analysis is a pretty complex problem in general case. Consider, for instance, function "f" has nested calls of other functions with "side effects", meaning they could potentially change the contents of "in" or "out" indirectly. For this reason, even current state-of-art commercial APIs that imply strong data analysis (like OpenACC

Reading the LLVM Programmer's Manual, the description of DenseSet mentions: *Note that DenseSet has the same requirements for the value type that DenseMap <http://llvm.org/docs/ProgrammersManual.html#dss_densemap> has.* But when I read about DenseMap, I don't really see any requirements for the values, just a warning about space. On the other hand, the *keys* have special

> > The MBlaze backend seems to be essentially unmaintained since 2011. The > maintainer (Wesley Peck who is BCC'ed) seems to have vanished, and in fact > all emails to him are bouncing. > I propose to remove the MBlaze backend on Friday if none step forward as a > maintainer. Currently, folks are having to keep it up to date when changing > shared parts of the backend

Hi, Using Chaitin's approach, removing a copy via coalescing could expose more opportunities for coalescing. So he would iteratively rebuild the interference graph and check for more opportunities. Chaitin was also careful to make sure that the source and destination of a copy didn't interfere unnecessarily (because of the copy alone); that is, his approach to interference was very

A GEP can represent a potentially large tree of instructions. Seems like all the sub-trees are hidden from optimization; that is, I never see licm or value numbering doing anything with them. If I rewrite the GEPs as lots of little adds and multiplies, then opt will do a better job (I speculate this happens during lowering). One of the computations that's hidden in the GEP in my example is

> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2

On 13.11.2012, at 10:46, erkan diken <erkandiken at gmail.com> wrote: Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to