[llvm-commits] [PATCH] Multidimensional Array Index Delinearization Analysis

Arnold Schwaighofer aschwaighofer at apple.com
Fri Oct 11 15:46:24 PDT 2013


On Oct 11, 2013, at 4:17 PM, Sebastian Pop <spop at codeaurora.org> wrote:

> Arnold Schwaighofer wrote:
> 
>> Interesting, in such a framework - if I understand you correctly - whenever we
>> simplify an expression we would have to try several assumptions: a harder
> 
> I think SCEV folding could compute the assumptions needed to simplify the
> expression. Let's take the example from the bug report:
> http://llvm.org/bugs/show_bug.cgi?id=16358
> 
>> 8 * (zext i32 ({0,+,2}%<for_body>) to i64)+ %C_aligned
>> 8 * (zext i32 ({1,+,2}%<for_body>) to i64)+ %C_aligned
>> Without knowing that for the loop <for_body> the functions "{0,+,2}%<for_body>"
>> and "{1,+2}%<for_body>" don’t wrap, SCEV cannot remove the zext.
> 
> simplify would recursively reconstruct the SCEV, so it would first dive in the
> innermost expression, and the first assumption it would extract is from
> simplifying (zext i32 ({0,+,2}%<for_body>) to i64)
> 
> simplify(zext i32 ({0,+,2}%<for_body>) to i64) = {0,+,2}%<for_body> assuming
> {0,+,2}%<for_body> does not wrap, i.e., 2*N < 2**32
> 
> simplify would produce two constraints:
> 
> 2*N < 2**32
> 2*N+1 < 2**32
> 
> we should keep the one satisfying both simplified expressions:
> 2*N+1 < 2**32


Okay, I see now. I was looking at the problem top down  - hence a tree of decisions :) - and was worried that for some examples we would have to guess a value. But bottom up we should have already seen such values. Right.

Thanks



More information about the llvm-commits mailing list