Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Avoid migrating existing patches. Phabricator shutdown timeline

Differential D5076 Diff 12967 test/Isl/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll

Changeset View

Standalone View

View Options

test/Isl/CodeGen/multidim_2d_parametric_array_static_loop_bounds.ll

; RUN: opt %loadPolly -polly-codegen-isl -S -polly-delinearize < %s | FileCheck %s ; RUN: opt %loadPolly -polly-codegen-isl -S -polly-delinearize < %s | FileCheck %s
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu" target triple = "x86_64-unknown-linux-gnu"
; Derived from the following code: ; Derived from the following code:
; ;
; void foo(long n, long m, double A[n][m]) { ; void foo(long n, long m, double A[n][m]) {
; for (long i = 0; i < 100; i++) ; for (long i = 0; i < 100; i++)
; for (long j = 0; j < 150; j++) ; for (long j = 0; j < 150; j++)
; A[i][j] = 1.0; ; A[i][j] = 1.0;
; } ; }
; CHECK: polly.split_new_and_old: ; CHECK: %[[T0:[._a-zA-Z0-9]]] = icmp sge i64 %m, 150
; CHECK: %0 = icmp sge i64 %m, 150 ; CHECK: %[[T1:[._a-zA-Z0-9]]] = select i1 %[[T0]], i64 1, i64 0
; CHECK: %1 = select i1 %0, i64 1, i64 0 ; CHECK: %[[T2:[._a-zA-Z0-9]]] = icmp ne i64 %[[T1]], 0
; CHECK: %2 = icmp ne i64 0, %1 ; CHECK: br i1 %[[T2]], label %polly.start, label %for.i
; CHECK: br i1 %2, label %polly.start, label %for.i
grosserUnsubmitted
Not Done
ReplyInline Actions

This test case explicitly tests that the computations for the run-time condition are created in the basic block that is named polly.split_new_and_old, the block in which we branch according to the run-time condition. This seems a good place to put those instructions.

It seems your patch changes this to now generate the instructions somewhere earlier. Where exactly? Was this intentional? In case it was, it would be good to explain the motivation/reason behind this.

Also, any changes to the generated IR seems suspicious in re-factorings that to my understanding aim to not change functionality.

grosser: This test case explicitly tests that the computations for the run-time condition are created in…
jdoerfertAuthorUnsubmitted
Not Done
ReplyInline Actions

The first part (the BB where the RTC is generated) is a valid comment. I will look into that anyway but I think we can generate it again in split_new_and_old or we can argue LLVM will move it there anyway.
However, the second part (about the IR change) is not helping at all. If you test for unnamed variables every little thing can change the result, even stupid stuff like the ordering of the basic blocks in the function. This would clearly be without functionality change but it could trigger your test...

jdoerfert: The first part (the BB where the RTC is generated) is a valid comment. I will look into that…
define void @foo(i64 %n, i64 %m, double* %A) { define void @foo(i64 %n, i64 %m, double* %A) {
entry: entry:
br label %for.i br label %for.i
for.i: for.i:
%i = phi i64 [ 0, %entry ], [ %i.inc, %for.i.inc ] %i = phi i64 [ 0, %entry ], [ %i.inc, %for.i.inc ]
%tmp = mul nsw i64 %i, %m %tmp = mul nsw i64 %i, %m
br label %for.j br label %for.j
Show All 18 Lines