search for: modrefbehavior

...; _srets["sample$int$float3"] = true; } void getAnalysisUsage(llvm::AnalysisUsage &usage) const { AliasAnalysis::getAnalysisUsage(usage); usage.setPreservesAll(); } bool runOnFunction(Function &F) { AliasAnalysis::InitializeAliasAnalysis(this); return false; } ModRefBehavior getModRefBehavior(CallSite CS, std::vector<PointerAccessInfo> *Info = 0) { if(_srets.find(CS.getCalledFunction()->getName()) != _srets.end()) return AliasAnalysis::AccessesArguments; // only accesses args, no globals return AliasAnalysis::getModRefBehavior(CS, Info); } ModRefBeh...

...uot;No", "Maybe", "Partial", and "Must" also seem awkward. Is there a better enum name than "AliasKind"? These aren't *just* results, so I don't like the current name. Whatever convention we use, we should use a similar one for the ModRef stuff. ModRefBehavior there already seems to have good names if it were switched to an enum class outside of AA. ModRefResult I would probably make ModRefKind, but maybe ModRefInfo? We call the methods getModRefInfo.... Please suggest patterns that you like! -------------- next part -------------- An HTML attachment wa...

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

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

----- 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 > >

...his still has the suffix problem in all except the "None" case... ) I like this colour: enum class AliasKind /* or AliasCategory? */ { Null, Unknown, Partial, Complete }; > Whatever convention we use, we should use a similar one for the ModRef stuff. ModRefBehavior there already seems to have good names if it were switched to an enum class outside of AA. ModRefResult I would probably make ModRefKind, but maybe ModRefInfo? We call the methods getModRefInfo.... > > Please suggest patterns that you like! > > ________________________________________...