[Hexagon] [Test] Remove undef and infinite loop from test

[hermord]

Summary

As suggested in D50222, this has been refactored into a separate patch.

The undef and the infinite loop at the end cause this test to be translated unpredictably. In particular, the checked-for mpy disappears under certain legal optimizations (e.g. the one in D50222). Since the use of these constructs is not relevant to the behavior tested, according to the header comment, this change, suggested by @kparzysz, eliminates them.

[lebedev.ri]

Right, this is accepted, i'll commit this for you then.

[lebedev.ri]

And reverted in rL341049.
Does this actually represent the llc output as of svn trunk?
Or is this dependent on D50222?

[hermord]

After a rebase and bisect, it turned out that the current form does rely on D50222. The extra mpy nodes come from this combine on the srem, which would not be reached with the proposed SREM optimization:

Combining: t11: i32 = srem t5, Constant:i32<3>
Creating constant: t36: i32 = Constant<1431655766>
Creating new node: t37: i32 = mulhs t5, Constant:i32<1431655766>
Creating new node: t38: i32 = mul t5, Constant:i32<0>
Creating new node: t39: i32 = add t37, t38
Creating constant: t40: i32 = Constant<31>
Creating new node: t41: i32 = srl t39, Constant:i32<31>
Creating new node: t42: i32 = add t39, t41
Creating new node: t43: i32 = mul t42, Constant:i32<3>
Creating new node: t44: i32 = sub t5, t43
 ... into: t44: i32 = sub t5, t43

Without the other changes in this patch, the srem was discarded and this did not happen.

This change fixes that: though there may be multiple mpys in the loop body, there is only one cmp; looking at it instead still fullfils the purpose of the test (ensuring the loop body is not duplicated), unless I'm mistaken.

[lebedev.ri]

@kparzysz this is still ok after the last change?

[hermord]

In D50944#1220392, @lebedev.ri wrote:

@kparzysz this is still ok after the last change?

Yes, I believe so. Tests pass successfully with this and this seems conceputally correct to me,

[hermord]

In D50944#1220545, @hermord wrote:

In D50944#1220392, @lebedev.ri wrote:

@kparzysz this is still ok after the last change?

Yes, I believe so. Tests pass successfully with this and this seems conceputally correct to me,

Oops my bad, misread the @. Please disregard.

[lebedev.ri]

I'm going to assume this is still ok and reland this.

[kparzysz]

test/CodeGen/Hexagon/swp-const-tc2.ll

10 ↗

(On Diff #163458)

It's the multiplication at line 25 that should only occur once. Could you change these two lines to

; CHECK: r{{[0-9]+}} = mpyi
; CHECK-NOT: r{{[0-9]+}} = mpyi

llvm/trunk/test/CodeGen/Hexagon/swp-const-tc2.ll

 ; RUN: llc -march=hexagon -rdf-opt=0 < %s | FileCheck %s
 
 ; Test that we fixup a pipelined loop correctly when the number of
 ; stages is greater than the compile-time loop trip count. In this
 ; test, there are two prolog stages, but the loop executes only once.
 ; In the bug, the final CFG contains two iterations of the loop.
 
 ; CHECK-NOT: loop0
-; CHECK: = mpy
-; CHECK-NOT: = mpy
+; CHECK: r{{[0-9]+}} = mpyi
+; CHECK-NOT: r{{[0-9]+}} = mpyi
 
-define void @f0() {
+define i32 @f0(i32* %a0) {
 b0:
   br label %b1
 
 b1:                                               ; preds = %b1, %b0
   %v0 = phi i32 [ 0, %b0 ], [ %v9, %b1 ]
   %v1 = phi i32 [ 0, %b0 ], [ %v8, %b1 ]
-  %v2 = load i32, i32* undef, align 4
+  %v2 = load i32, i32* %a0, align 4
   %v3 = add nsw i32 %v1, 1
   %v4 = srem i32 %v2, 3
   %v5 = icmp ne i32 %v4, 0
   %v6 = sub nsw i32 0, %v2
   %v7 = select i1 %v5, i32 %v6, i32 %v2
   %v8 = mul nsw i32 %v3, %v7
   %v9 = add nsw i32 %v0, 1
   %v10 = icmp eq i32 %v9, 1
   br i1 %v10, label %b2, label %b1
 
 b2:                                               ; preds = %b1
   %v11 = phi i32 [ %v8, %b1 ]
   br label %b3
 
 b3:                                               ; preds = %b3, %b2
-  br label %b3
+  ret i32 %v11
 }