[PATCH] D35471: [Polly] [RFC] Calculate AST expression type

[Tobias Grosser via Phabricator via llvm-commits]

grosser added a comment.

Hi Johannes,

just to clarify. I never said your approach is wrong or has an entirely wrong design, but said that a similar approach caused issues in graphite, hence I would like to understand your patch in detail before going this road. I still don't fully understand how this works, but tried some simple examples with https://llvm.org/svn/llvm-project/polly/trunk@271878. Maybe you can cross-check if what I observe is the intended behavior of your patch.

  define void @foo32(float* %A, i32 %n) {
  entry:
    br label %loop
  
  loop:
    %indvar = phi i32 [0, %entry], [%indvar.next, %loop]
    %indvar.next = add nsw i32 %indvar, 1
    %cmp = icmp slt i32 %indvar, %n
    store float 1.0, float* %A
    br i1 %cmp, label %loop, label %exit
  
  exit:
    ret void
  }
  
  define void @foo64(float* %A, i64 %n) {
  entry:
    br label %loop
  
  loop:
    %indvar = phi i64 [0, %entry], [%indvar.next, %loop]
    %indvar.next = add nsw i64 %indvar, 1
    %cmp = icmp slt i64 %indvar, %n
    store float 1.0, float* %A
    br i1 %cmp, label %loop, label %exit
  
  exit:
    ret void
  }

when I change the schedule from [i] -> [i + 1024] (using jscop to simulate a scheduler which decides to perform skewing) I get the following ASTs:

  foo32:
  if (1)
  
      {
        for (int c0 = 1024; c0 <= n + 1024; c0 += 1)
          Stmt_loop(c0 - 1024);
        if (n <= -1)
          Stmt_loop(0);
      }
  
  foo64:
  
  if (1)
  
  
      {
        for (int c0 = 1024; c0 <= n + 1024; c0 += 1)
          Stmt_loop(c0 - 1024);
        if (n <= -1)
          Stmt_loop(0);
      }

The code that is generated for foo32 to model the addition n + 1024 is:

  %0 = sext i32 %n to i33
   %1 = add nsw i33 %0, 1024

This seems to be correct. Also, in general, I feel that generating non power-of-two types is something we should better avoid.

The code that is generated for foo64 to model the addition n + 1024 is:

  %0 = add nsw i64 %n, 1024

but it seems no run-time bounds checks are generated. Your commit message says: " If the type adjustment is not possible, thus the necessary type is bigger than the type value of --polly-max-expr-bit-width, we will use assumptions to verify the computation will not wrap."  hence I would expect a RTC to be generated. Is the behavior I observe the expected behavior?


https://reviews.llvm.org/D35471