similar to: How to extend alias analysis to enable further optimisations?

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

On Mon, 25 Apr 2005, Vladimir Prus wrote: > The GlobalsModRef::getModRefInfo has this logic: > > // If we are asking for mod/ref info of a direct call with a pointer to a > // global we are tracking, return information if we have it. > if (GlobalValue *GV = const_cast<GlobalValue*>(getUnderlyingObject(P))) > if (GV->hasInternalLinkage()) > > So, no

Hi all, I want to find memory dependency between CallInst instruction and other. So i used the following code: * AliasAnalysis &AA=getAnalysis<AliasAnalysis>();* * if(isa<StoreInst>(inst1)){* * ** **if(isa<CallInst>(inst2))**{* * CallInst *call_inst2= dyn_cast<CallInst>(inst2); * * if(AA.getModRefInfo(inst1,call_inst2)==mod)**{* *

i am sorry, i get this error: opt: /home/llvm/src/include/llvm/Support/CallSite.h:87: ValTy* llvm::CallSiteBase<FunTy, ValTy, UserTy, InstrTy, CallTy, InvokeTy, IterTy>::getCalledValue() const [with FunTy = const llvm::Function, ValTy = const llvm::Value, UserTy = const llvm::User, InstrTy = const llvm::Instruction, CallTy = const llvm::CallInst, InvokeTy = const llvm::InvokeInst, IterTy =

Hi neda 8664, > I want to find memory dependency between CallInst instruction and other. So i > used the following code: > > > > / AliasAnalysis &AA=getAnalysis<AliasAnalysis>();/ > > /*if* (isa< StoreInst >(inst1)){ / > > // // /*if* (isa<CallInst>(inst2)) / /{/ > > / CallInst *call_inst2= dyn_cast<CallInst>(inst2); /

On Tue, Oct 10, 2017 at 1:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 10/10/2017 02:49 PM, Alina Sbirlea wrote: > > Sigh >> I should have taken the time to give a better example. >> The must-alias part is irrelevant to an example (it only requires >> read-onlyness) >> >> You said "LICM doesn't move calls, so we'd never really

On Monday 25 April 2005 23:40, Chris Lattner wrote: > On Mon, 25 Apr 2005, Vladimir Prus wrote: > > The GlobalsModRef::getModRefInfo has this logic: > > > > // If we are asking for mod/ref info of a direct call with a pointer > > to a // global we are tracking, return information if we have it. > > if (GlobalValue *GV = > >

> In your new proposal, doing & on the result of getModRef() may yield unexpected results. Agreed. I made the change I proposed locally, and, while it simplifies some cases, it makes other bit-wise operations look unintuitive. > Maybe we should just hide all that in inline functions or something and make it an enum class Noted, and looking into this option. Hoping a couple of static

Hi Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value

On Jan 3, 2012, at 1:53 PM, Jianzhou Zhao wrote: > I see. I asked the question because LLVM provides several alias > analysis, and I was wondering how to decide which one should be used > for compiling most programs. > > I think the basicaa is the default one, but by looking into its code, > it is not inter-procedural or context-sensitive (I am not 100% sure), > so does not

Duncan, thanks for your answer! > 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 work. (The

On Tue, Jan 3, 2012 at 3:54 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 2, 2012, at 9:42 PM, Jianzhou Zhao wrote: > >> Hi, >> >> Chapter 4 in http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html >> compares the precision of alias analysis in LLVM at that time. Does >> the latest LLVM still follow the similar results? I was also

Based on function names and structures, this is some version of GCC :) Any way you can post the entire .ll file? Because it's globalsmodref, it's hard to debug without the other functions, since it goes over all the functions to determine address takenness, etc :) On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Chandler, > > We

Thanks guys! I was looking into ModRef before, but I don't think that's exactly what I need. ModRef API call getModRefInfo requires a Value to be passed to it. However, some memory location M (which is a <DSNode, offset> pair) visible to the caller can be modified in the callee without any Value in the caller actually pointing to that location. I also need to capture those... I

On Thu, Apr 3, 2008 at 4:53 PM, Zvonimir Rakamaric <zrakamar at gmail.com> wrote: > Thanks guys! > > I was looking into ModRef before, but I don't think that's exactly > what I need. ModRef API call getModRefInfo requires a Value to be > passed to it. However, some memory location M (which is a <DSNode, > offset> pair) visible to the caller can be modified

Dear all, I was wondering if there are some reliable alias analyses build on top of LLVM other than basicaa. Thank you! Zhiyuan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150407/db07dba3/attachment.html>

Yes, this is odd. On my clang.bc Without: 2.2967 ( 53.8%) 0.0242 ( 26.4%) 2.3210 ( 53.2%) 2.3227 ( 53.2%) Memory SSA 2.3364 ( 53.7%) 0.0246 ( 25.7%) 2.3610 ( 53.1%) 2.3636 ( 53.1%) Memory SSA 2.3353 ( 54.0%) 0.0258 ( 27.0%) 2.3611 ( 53.4%) 2.3632 ( 53.3%) Memory SSA With two getModRefInfo calls: 3.0302 ( 58.8%) 0.0328 ( 29.9%) 3.0630 ( 58.2%) 3.0858 ( 58.2%)

I am often asked what optimisations "our" compiler performs at each level. But "our" compiler is actually CLang/LLVM which we have retargeted to our proprietary target. Most of the work we do is in maintaining our target specific backend. Certainly there are optimisations that we do to take best advantage of our instruction set during lowering and instruction selection, and

Hi Xin, Thank you for your reply! I have tried the 3 alias analyses you have mentioned on LLVM 3.5: 1) $ opt -globalsmodref-aa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 2) $ opt -tbaa -aa-eval < xxx.bc > /dev/null (May-alias response 100%) 3) $ opt -cfl-aa -aa-eval < xxx.bc> /dev/null (Unknown command line argument '-cfl-aa') It seems that they are not