search for: accessesargu

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

...ol 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); } ModRefBehavior getModRefBehavior(Function *F, std::vector<PointerAccessInfo> *Info = 0) { if(_srets.find(F->getName()) != _srets.end()) return AliasAnalysis::AccessesArguments; // only a...

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

...;s been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been successful with this approach and hope that someone has an idea on how to fix this. Here's a step by step illustration of the problem: 1. The following source code is compiled ... intrinsic float4 sample(int tex, fl...

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is