similar to: [LLVMdev] Missed vectorization opportunities?

Hi, For the program below, where "incr" and "Arr" are globals ================================= int incr; float Arr[1000]; int foo () {   float x = 0;   int newInc = incr+1;   for (int i = 0; i < 1000; i++) {     for (int j = 0; j < 1000; j += incr) {         x += (Arr[i] + Arr[j]);     }   }   return x; } ================================= The SCEV expression computed

Hi, I observed below behavior with Instruction combiner (visitMul Canonicalization) It tries to convert "(X+C1)*C2" to "X*C2+C1*C2" While transforming if operation is guaranteed to not overflow it does not reflect same property to transformed instructions. Consider following scenarios: 1) If input is ((X+C1)*C2)<nsw> Then post canonicalization output should be

Hi James, Thanks for the help. From the log, I could infer that SLP vectorizer is not preserving alias analysis, preventing GVN from getting the info. Although the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular

>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should). I didn't realise that adding GlobalsAA* after* SLPVectorizer could help. Thanks for this tip. >There is something fishy. Do you have a test case that reproduce with llvm-lto? I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it.

Hi Mehdi, Thank you for the response. I'm actually on an LTO setup and was referring to PassManagerBuilder::addLTOOptimizationPasses. Here, GlobalsAA is scheduled to run well ahead of SLPVectorizer. However since GlobalsAA is a module pass, it runs once and a bunch of passes, including SLPVectorizer is run for each function. When one of them invalidates the analysis, rest of the functions do

Thank you both for the inputs. I've created a patch for the same, please review: http://reviews.llvm.org/D15185 >You can specifically insert it into the pass pipeline, but in this case, we should just fix SLP to preserve the analysis. @Hal, I tried doing this but it didn't seem to work. I added the GlobalsAA pass right before GVN but it didn't seem to help. In retrospect, looking

On Wed, Feb 24, 2016 at 11:44 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> The only optimizations I can think of that are okay are algebraic >> simplifications that don't exploit no-overflow, inbounds or exact > > Why? Can you provide an example using nsw, inbounds, etc.? I think the same case as the general UB applies: void foo(int n) available_externally { if (n

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

Hi, I've noticed that alias analysis queries arising from GVN do not use the results from GlobalsAA. The last call to AAResultsWrapperPass::runOnFunction() before GVN does not add GlobalsAAWrapperPass due to unavailability. This leads to the alias queries from GVN not having any globals mod-ref info. Is this a known issue? and is there any way to have globals mod-ref info available for GVN?

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

that would be an escaping global, and as far as I know is handled separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global is used as operand to a function) On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >It is if one of the operands is or can alias a global ? >On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at

Hi list, I'm using R 2.8.1 under Windows vista. I have the following problem: First of all I create a string-vector. Then I "convert" these strings into variables and assign a vector of numeric values. So far everything's fine. Now I want to do nearly the same again: I create another string-vector and I want to assign the variance. So I have to loop over the first

> On Dec 4, 2015, at 10:33 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Vaivaswatha Nagaraj" <vn at compilertree.com> >> To: "James Molloy" <james at jamesmolloy.co.uk>, "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvm-dev at

>there would be two disjoint global states In some sense yes, but technically not disjoint. Functions marked with this attribute should still be able to access the globals within the program under compilation, if its not marked with ReadNone. >If malloc and free can both use global variables (there is no notion of library in the compiler) Inaccessible state here refers to any global that is

>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

>What if you had bitcode versions of your C library Then the definitions for these functions would be available. Would we still set function attributes to these functions in FunctionAttrs.cpp if their definitions were available? >This also seems a bit tailored to malloc/free, and can't work for user-defined allocation functions I don't think so. For example, printf would have the

Thanks for your insides Sanjoy! I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved). We can speculate about what is "simple enough" to not cache the ranges, but I believe that there is

writing into operands is not the same as writing to globals right? I added printf in the same category since we were discussing writing to globals. On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >Hi, > >I just want to reiterate: printf and friends do *not* fall into this >category as they can write to their operands (unless you parse

Hello Everyone, I want to raise a discussion about reasonability of late setting of nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion about this have already happened in August last year, there was a concern about different no-wrap flags that come from different sequences of SCEV flags invocations. It was mentioned there that late setting of flags is actually a hack 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