search for: onlyreadsmemori

Using the following example program #include <math.h> double f(double d){ return sqrt(d); } and compiling it with "clang -O3 ...", I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a sqrtsd instruction inline. It turns out that it could do exactly that, were it not for the fact that in the function

Hi, GlobalsAA, during propagation of mod-ref behavior in the call graph, looks at library functions (in GlobalsAAResult::AnalyzeCallGraph: F->isDeclaration() check), for attributes, and if the function does not have the onlyReadsMemory attribute set, forgets it. I noticed that library functions such as malloc/realloc do not have the attributes doesNotAccessMemory or onlyReadsMemory

On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Using the following example program > > #include <math.h> > > double f(double d){ > return sqrt(d); > } > > and compiling it with “clang –O3 …”, I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a

Hi James, Thank you for the response. I understand the concern about malloc/free hooks. Could we detect that a program has setup malloc hooks (assuming we're in a whole program compilation) and make assumptions (such as onlyAccessesArgMem()) when the program hasn't setup malloc hooks? Using a command line flag could be one option too. I'm currently working on a program where having

I am probably stating the obvious, but if the function is side-effect free (onlyReadsMemory) it is valid to remove it. But I am guessing that does not belong to this pass. On Wed, Aug 24, 2016 at 8:38 AM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Btw, looks like the bug is in runSCCP in > > for (BasicBlock::iterator BI = BB.begin(), E = BB.end(); BI !=

Hello, Is there a analysis pass which calculates the ModRefBehaviours OnlyReadsPointerArguments and OnlyAccessesPointerArguments? I tried to find one but so far I only saw that different AA's return OnlyReadsMemory and DoesNotAccessMemory if the readonly and readnone attributes are set. Best regards and thanks in advance, Johannes -- Johannes Doerfert Researcher / PhD Student

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

Does fast-math imply no-math-errno ? Thanks, Nadav On May 17, 2013, at 15:36, Chris Lattner <clattner at apple.com> wrote: > > On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > >> Using the following example program >> >> #include <math.h> >> >> double f(double d){ >> return sqrt(d);

From: Villmow, Micah Sent: Tuesday, November 06, 2012 1:37 PM To: 'llvm-dev at cs.uiuc.edu' Cc: Guo, Xiaoyi Subject: Bug in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different

void SelectionDAGBuilder::visitTargetIntrinsic(const CallInst &I, - unsigned Intrinsic) { - bool HasChain = !I.doesNotAccessMemory(); - bool OnlyLoad = HasChain && I.onlyReadsMemory(); + unsigned Intrinsic) { + // Info is set by getTgtMemInstrinsic + TargetLowering::IntrinsicInfo Info; + bool

<<< I may misunderstand, but it seems to me that this solves only query for aliasing with a pointer known to be pointing only to globals defined in the current compilation unit. For any pointer which "may point somewhere else”, you won’t be able to resolve the non-aliasing with the “internal state” for malloc/free, right? To take the original example in this thread: int *x =

Hi, This email is in continuation to the mail thread http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html, to propose a new function attribute that can convey that a function maintains state, but this state is inaccessible to the rest of the program under compilation. Such a flag could be added to most libc/system calls such as printf/malloc/free. (libc and system calls do

>is this "internal state” supposed to be private to the function? It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state. >how this flag would prevent the last “optimization”

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Joseph Tremoulet" <jotrem at microsoft.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 1:28:05 PM > Subject: Re: [llvm-dev] RFC: New function attribute

>but is there or is there not accessible, visible state, Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means it doesn't access any of the visible (accessible) states. - Vaivaswatha On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I don't think the attribute as is is strong enough to do what you

I'm trying to understand what is the result we'd seek in the example in D38569 (pasting here for quick access) double f(double a) { double b; double c,d; double (*fp) (double) __attribute__ ((const)); /* Partially redundant call */ if (a < 2.0) { fp = sin; c = fp (a); } else { c = 1.0; fp = cos; } d = fp (a);

Hi Stephan, >> In order to perform this transform the optimizers would have to work out >> that sample does not modify any global state. This cannot be done without >> knowing the definition of sample, but you only provide a declaration. > > Which is why I am trying to supply this additional information in a > custom alias analysis pass, but it doesn't seem to

>what is a non-public state that no-one but you can access? (I’d call that private). malloc and free could both use global variables that are defined in libc, but are inaccessible to the program under compilation. >if you’re attribute is saying they have some internal state, then malloc() cannot access the state of free() and vice versa. Which is why it would be preferable to call it

----- Original Message ----- > From: "Joseph Tremoulet" <jotrem at microsoft.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 3:35:38 PM > Subject: RE: [llvm-dev] RFC: New function attribute

Hi Félix, Sanjoy Das wrote: > Félix Cloutier via llvm-dev wrote: > > Assuming that this is a bug, what are the next steps? > > Looks like you already have a very small test case -- have you tried > sticking it in a debugger to see why SCCP thinks removing the call is > okay? > > Alternatively, file a bug at llvm.org/bugs and someone will get to it. The third