[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